Jeffrey Hutzelman writes:On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost> wrote: > At the end of Section 7.1, add the following two paragraphs: > > Once a party has sent a KEXINIT message for key exchange or > re-exchange, it MUST NOT send any messages other than key exchange > method specific messages (message numbers 30 to 49); NEWKEYS; and > DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message > (Section 7.3). Implementations MUST NOT accept messages other than > these between receiving KEXINIT and NEWKEYS messages. Uh, what's wrong with SSH_MSG_UNINPLEMENTED?
And what's wrong with other (not yet defined) messages in the 20-29 range? Without these, it will become difficult to extend algorithm negotiation, which I know we've discussed in the past.In principle yes, but at this point I'd be inclined to defer resolving this to such time as such extensions are actually defined. (I admit that this is partly due to the IESG's apparent paranoia about over-extensibility; I don't want to see the drafts being held up again on my account if there's some gremlin we haven't thought of.)
That doesn't help. The issue is that in order to extend the exchange in the future, an new peer needs to be able to send a not-yet-defined message to an old peer and get SSH_MSG_UNIMPLEMENTED back. In order for that to work, old peers must accept the not-yet-defined message and return SSH_MSG_UNIMPLEMENTED, rather than ignoring the not-yet-defined message or deciding to disconnect (either of which would appear to be OK -- we don't define what happens if you get a message that you MUST NOT accept).
For that matter, I'm not convinced that the not-yet-defined messages in the 1-19 range should be excluded either. All of the defined messages in this range have meaning at the lowest layer, independent of key exchange state.Are you really suggesting that SERVICE_REQUEST and SERVICE_ACCEPT should be permitted during key exchange?
No. Those don't fall in the realm of not-yet-defined, and clearly should be excluded.
If we're unhappy with SERVICE_REQUEST and _ACCEPT (as I think I am), then future messages in this range may have the same undesirable properties as them.
Well, it's expected that current implementations MUST NOT send not-yet-defined messages at all, until they are defined.
The issue is with what current impleentations do when they receive a not-yet-defined message. If we ever want to extend the protocol cleanly, they need to respond with SSH_MSG_UNIMPLEMENTED and otherwise do nothing, just as they would at any other time. This isn't a general-purpose extension mechanism to be used by anyone who wants to, but it _is_ key to making it possible to define a future rev of the protocol which interoperates with this one but includes new messages (sadly, we can't just bump the protocol version, because we failed to define a way to indicate support for any version beyond 2.0 while also supporting the 1.x protocol).
Again, if we decide in the future that message 17 should be permitted during rekey, a new implementation won't be able to discover if its peer support message 17 unless implementations that don't know what that is are expected to send SSH_MSG_UNIMPLEMENTED.
On the other hand, if we decide that message 17 should _not_ be permitted during rekey, all we have to do is say that when we define message 17. Then new implementations will not send message 17 during rekey, and will not accept it if they see it then. Old implementations will continue to send SSH_MSG_UNIMPLEMENTED, but that shouldn't be a problem.
-- Jeff