Re: Data transfer during key re-exchange

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

Jacob Nevins wrote:
> What happens to "application data" (connection protocol etc) during a
> key re-exchange is still not specified by the current transport draft
> (transport-18).
>
> This has come up at least three times. The WG decision made by Bill
> Sommerfeld[1] was that non-rekey-related traffic should be suspended for
> the duration of the rekey, but this was not implemented in the draft.
>
>   [1] 19 Oct 2003, thread 'Some questions about "SSH Transport Layer
>       Encryption Modes"', <200310192351.h9JNpxAx004282%thunk.east.sun.com@localhost>
>
> Therefore, I propose the following change for the transport draft:
>
> In section 9 "Key re-exchange", between the last two paragraphs, insert
> the following paragraph:
>
>   Once a party has sent a KEXINIT message for key re-exchange, it MUST
>   NOT send any messages other than DISCONNECT, IGNORE, and DEBUG;
>   NEWKEYS; and key exchange method specific messages (message numbers
>   30 to 49); until it has sent a NEWKEYS message.  Note however that
>   after sending a KEXINIT message, each party MUST be prepared to
>   process an arbitrary number of received messages that may be "in
>   flight" before seeing a KEXINIT from the other party.
>
> If anyone has objections, this issue should at least go in the issue
> tracker, so it doesn't get lost again.

Every time this discussion has come up before I've looked for
the language that I knew was there in section 7.1, and then
found it in section 7.3 (which really is quite clear, if misplaced)

   This message [NEWKEYS] is the only valid message after
   key exchange, in addition to SSH_MSG_DEBUG,
   SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages....
   Implementations MUST NOT accept any other messages
   after key exchange before receiving SSH_MSG_NEWKEYS.

And in section 9,

   Re-exchange is processed identically to the initial key exchange,
   except for the session identifier that will remain unchanged.

I've never quite understood the confusion on this issue... however,
I don't object to the new text.  I do object to it's proposed
location though... I think it should go in Section 7.1 and section
7.3 could be condensed a little bit to remove redunancy.

If a re-enforcing sentance is needed in section 9 (processed identically
including valid packet restrictions) I wouldn't mind that.

I would strike the final paragraph of section 9-- it is wrong (key 
exchanges _does_ affect the protocols because we stop sending their
data for the duration) and only introduces confusion about an issue that 
is pretty well specified otherwise.  I guess we could reword it as our 
re-enforcing sentance:

   Application data MUST NOT be sent after KEXINIT and prior to  the
   SSH_MSG_NEWKEYS packet; other than this restiction, key exchange
   does not affect the protocols that lie above the SSH transport layer.

- Joseph