Subject: RE: SFTP version negotiation

From: Richard Whalen <[email-masked]>
Date: Mon, 4 Oct 2004 09:29:41 -0400

I think that this would be very unusual, as each new version has been a
superset of protocol of the previous version.

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.

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.

-----Original Message-----
From: Henrick Hellström [mailto:[email-masked]]
Sent: Sunday, October 03, 2004 6:59 AM
To: [email-masked]
Subject: SFTP version negotiation

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.

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 05 Oct 2004 13:25:37 +0200

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

> packet.  This method of negotiation may not be possible in all

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

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

---

From: [email-masked] (Niels Möller)
Date: 05 Oct 2004 17:48:13 +0200

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

Regards,
/Niels

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 05 Oct 2004 10:33:13 -0600

> Let's keep things simple.

On the other hand, I was thinking we might have more
people adopt the next version if they didn't have to
support version 4 and 5 in addition to 6.

And since documents describing version 4 and 5 are not
longer available (at least from IETF) and I don't want
to drag cruft documenting older version in the current
version of the draft, it seems prudent to allow people
to skip a version while implementing.

This unfortunate situation is mostly my fault... because
it has taken so long to finish the spec, we have
implementations that are well entrenched at version 3.
Unfortunately, I'm afraid that the two different
version negotiations is the sign of a protocol
specification period that has lasted too long.

I think it will be simplier in the long run
to have the double version negotiation than
to have popular servers/clients that never
move off of version 3 because version 4 & 5
specifications aren't available, and they
can't maintain backwards compatibility without
those specs.

Thanks,

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 05 Oct 2004 21:12:02 +0200

> implementations that are well entrenched at version 3.

The situation is somewhat unfortunate, but I do *not* think we have a
sufficient motivation for introducing a new version negotiating
mechanism in the spec.

Implementations that want to support version 3 and 6, but no version
in between, can do that in several ways; an explicit command line
option, or the "try version 6, if the server supports only 4 or five,
disconnect and try again with 3".

That's a little kludgy, true. But if we have to choose between

  1. Kludges in the implementations, which will live only until
     version 6 is sufficiently widespread that version 3 support can
     be dropped (I think all serious sftp implementations should get
     version 6 support within a year, or at most, say, three years),

  2. Kludges in the spec, which will live forever and affect every
     implementation that is ever written,

I'll choose 1 every time. Please.

/Niels