Richard Whalen wrote:
I think that this would be very unusual, as each new version has been a superset of protocol of the previous version.
Nope. For instance, version 3 and version 5 are incompatible, since they use different status response formats and different attribute structs.
One option that the client could take would be to send an SSH_MSG_CHANNEL_CLOSE, which will close the SFTP server, then go back to the sequence of SSH_MSG_CHANNEL_OPEN, SSH_MSG_CHANNEL_REQUEST for the subsystem, but this time drop the version of SFTP requested to 3 in the SSH_FXP_INIT packet. This method of negotiation may not be possible in all implementations.
It is at least consistent with the specification, and appears to be the way to go.
I was mostly interested in (a) if there was a "better" way that didn't require the SFTP sub system to be closed and re-opened, plus (b) why this version negotiation mechanism was selected to begin with, and not e.g. one in which the client would send a list of each supported version (which is more or less how the rest of SSH works).
Another option, would be to add language to the draft specifying that an implementation must be able to support all lower version numbers. This would require that the draft continue to include sufficient history to allow developers to keep track of what was added in the various versions.
This might not be the options. Consider, for example, the possibility that an addition to the SFTP protocol made in one version turns out to introduce a security flaw that is later fixed in the next version.