Re: Data transfer during key re-exchange

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

Joseph Galbraith writes:
> 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).
    [snip my suggestion]
> > 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)
  [snip]
> And in section 9,
  [snip]
> 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.

Fair enough.

> 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:
  [snip]

OK. How about this for a proposed change to transport-18?:

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.

   Note however that during a key re-exchange, 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.

Replace the last paragraph of Section 7.3 ("This message is [...]
receiving SSH_MSG_NEWKEYS.") with the following paragraph:

   The purpose of this message is to ensure that a party is able to
   respond with a SSH_MSG_DISCONNECT message that the other party can
   understand if something goes wrong with the key exchange.

Replace the last paragraph of Section 9 ("More application data [...]
SSH_MSG_NEWKEYS is sent") with the following paragraph:

   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.

(For convenience I've put a marked-up copy of transport-18 at
<http://www.chiark.greenend.org.uk/~jacobn/2004/07/ssh2-kex-data-diff.html>.)