Re: SFTP v6?

[nisse%lysator.liu.se@localhost (Niels Möller)]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

> This is almost the way it works, but not quite.
> 
> V_C = max { version numbers supported by the client }
> V_U = highest version supported by server <= V_C
> 
> (V_S doesn't actually exist on the wire.)

Thanks for the correction. Let's see if I understand what this implies
for interoperability. The failure, for traditional version exchange,
seems to be

  * Client supporting version 3 and 6.
  * Server supporting version 3 and 4.

  =>  V_U = 4  =>  communication failure.

Is this correct?

> So I'll make an alternate proposal:

[...]

> Therefore, I suggest that we change the name of the subsystem
> to 'file-share'
> 
> The 'file-share' protocol supports all versions of the 'sftp'
> protocol, with the minor exception that version exchange
> consists of:
> 
> Server and client both send (without waiting to receive):
> 
> FXP_INIT2
> string version-list
> <extension-data>
> 
> version-list is comma separated string of versions,
> in order of preference.  For example.  "6,2,1"

I agree this is a clean solution, in line with how the rest of the ssh
protocol works. However, let's compare how it will work in practice
during the transition period (next few years), with particular focus
on our failure case: a client supporting versions 3 and 6, and an old
server supporting versions 3 and 4.

  1. Client asks SSH server for subsystem "file-share".

  2. SSH server replies failure.

  3. Client asks for subsystem "sftp".

  4. SSH server replies success, and starts the subsystem.

  5. Client sends V_C = 3 (servers supporting version 6 are supposed
     to support "file-share", so there's no point of asking for
     version 6 at this point).

  6. The sftp server selects V_U = 3.

  7. Handshaking is finished and sftp version 3 is used for the rest
     of the session.

Do I understand your proposal correctly? Now compare this to the
"kludge" that can be used without any changes to the current protocol:

  1. Client asks SSH server for subsystem "sftp"

  2. SSH server replies success, and starts the subsystem.

  3. Client sends V_C = 6.

  4. Server replies V_U = 4.

  5. Client terminates session, since it doesn't support version 4.

  6. Client asks SSH server for subsystem "sftp"

  7. SSH server replies success, and starts the subsystem.

  8. Client sends V_C = 3.

  9. Server replies V_U = 3.

 10. Handshaking is finished and sftp version 3 is used for the rest
     of the session.

In this case (which I think is the most central problematic case which
we're trying to address) I don't see a big win in introducing
"file-share". It makes things only slightly easier for the client, and
slightly more complex for the server.

And when having this choice, I usually prefer putting the complexity
in the client. The reason is that complexity always increases the risk
for bugs, and bugs usually have a much worse security impact in the
server than in the client.

Best regards,
/Niels