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.
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. Why do we think any future messages in this range won't have the same property?
I'd say permit any messages in the 1-49 range, with the possible exception of SSH_MSG_KEXINIT itself. Note that this must be handled carefully - once you send a KEXINIT, you're not allowed to _send_ another one, but you certainly are allowed to _receive_ one if you haven't seen it yet. The text you propose seems clear enough to me in this regard; an implementation that gets this wrong won't be able to rekey at all!
Key exchange does not affect the protocols that lie above the SSH transport layer, except that such protocol data MUST NOT be sent after a SSH_MSG_KEXINIT is sent but before a SSH_MSG_NEWKEYS is sent.
It occurs to me that what we're really trying to say is "key exchange does not affect the STATE OF protocols that lie above the SSH transport layer...". It can introduce arbitrary delay, but that's it.
-- Jeff