Henrick Hellström <henrick%streamsec.se@localhost> writes:
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
As for b), my guess is that it was expected that
1. version updates would mostly be backwards compatible, and that
2. the number of versions in use at any given time would be small,
typically one old version and one newer.
I think these are reasonable assumptions, once the sftp spec matures.
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).
The ssh version exchange (section 4.2 of the transport draft) does't
work the way you describe. To me, it makes a lot of sense to treat
version exchange and algorithm negotiation (which I suspect is what
you're referring to) quite differently.
I don't think it is motivated to introduce any more complex version
negotiation at this time. If I were to read a protocol specification
with two different version negotiation mechanism in it, my immediate
reaction would be that the spec must be a bloated comittee product.
Let's keep things simple.