Re: SFTP version negotiation

[Damien Miller <djm%mindrot.org@localhost>]

Joseph Galbraith wrote:
> Henrick Hellström wrote:
> 
>>Just a thought...
>>
>>What happens if a SFTP server supports v3 and v4, and a client that 
>>supports v3 and v6 only connects?
>>
>>According to the latest draft, they are supposed to start v4, since the 
>>client will send v6 and the server supports at most v4, and v4 is the 
>>least of these two numbers.
>>
>>Quoted from draft 05:
>>
>>4. Protocol Initialization
>>
>>   When the file transfer protocol starts, the client first sends a
>>   SSH_FXP_INIT (including its version number) packet to the server. The
>>   server responds with a SSH_FXP_VERSION packet, supplying the lowest
>>   of its own and the client's version number.  Both parties should from
>>   then on adhere to particular version of the protocol.
> 
> 
> This has been a concern of mine for a while.  The best solution I've 
> been able to come up with (better than closing channel, I think) is this:
> 
>  > If the client supports non-contigous version, for example,
>  > versions 2,3, and 6, then the INIT/VERSION negotiation
>  > is insufficient.  In order to gaurentee a successful
>  > connection, the MUST send the highest version for which
>  > it supports all previos version (because the server
>  > might pick the version the client sends or any
>  > previous version.)
>  >
>  > However, in order to work around this limit in the
>  > deployed protocol implementations, after the
>  > INIT/VERSION exchange is complete, if the version
>  > negotiated is at least 3, the version where extensions was
>  > introduced, the client MAY send the following extension
>  > to attempt to negotiate a higher version:
>  >
>  >   byte SSH_FXP_EXTENDED
>  >   uint32 request-id
>  >   string "version-negotiate"
>  >   uint32 highest version-supported
>  >   uint32 2nd highest version-supported
>  >   ...
>  >   uint32 lowest version-supported

I'm in two minds about this: we need some way to negotiate versions, but
this effectively eliminates the usefulness of the version sent at
protocol start, which is going to have to negotiate to 3 for the
foreseeable future.

As far as the protocol itself, we could use the extended data in the
SSH_FXP_INIT packet to indicate protocol support. e.g.

byte SSH_FXP_INIT
uint32 version
string "version-negotiate"
string highest-version-supported,2nd-highest-version,...

The return SSH_FXP_VERSION packet can do the same. The client and server
then pick the first common item from the lists. Every SSH implementation
is going to have code for matching this sorts of list of comma separated
strings, so I think it makes sense to reuse it. This also saves a
round-trip at protocol start.

Another alternative would be to do a new protocol start message with
proper version negotiation and rename the subsystem (e.g. "sftp2"), but
I think that this is overkill.

-d