Subject: Data transfer during key re-exchange

From: Jacob Nevins <[email-masked]>
Date: Fri, 25 Jun 2004 14:35:57 +0100

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"', <[email-masked]>

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.

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 28 Jun 2004 10:19:29 -0600

> 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