Re: SFTP version negotiation

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Damien Miller wrote:
> 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,...

Unfortunately, we were forced to remove SSH_FXP_INIT
extension data because it broke compatibility with
down-level servers.

(I.e., the client has to send the INIT packet before
it knows that the server is a mature enough version
to understand about extensions.)

> The return SSH_FXP_VERSION packet can do the same. The client and server
> then pick the first common item from the lists.

We could have the server send it's list of supported versions
as part of the FXP_VERSION packet and then allow the client
to request that the server switch to one of the listed
versions... but that doesn't save the round trip, since the
client still has to do the switch as an extension w/ a round
trip.

> 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.

I considered the string version, and I'm definitely not opposed
to going that route.  It was really just a flip of a coin for
me...

- Joseph
I thought about using the string version of this... and
I didn't

The server could

> 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