Application data during key re-exchange

[nisse%lysator.liu.se@localhost (Niels Möller)]

I'm sorry if this has been discussed before, but I don't remember the
outcome.

Consider a key re-exchange, and for simplicity, assume we're using the
diffie-hellman-group1-sha1 method. This is what happens:

  Client sends  Server sends
1 KEXINIT       KEXINIT       (in arbitrary order, or simultaneously)
2 KEXDH_INIT
3               KEXDH_REPLY
4               NEWKEYS
5 NEWKEYS

Can this message exchange be interleaved with other messages? More
precicely, is the server allowed to send other messages between 1 and
3, or between 3 and 4? Is the client allowed to send other messages
between 1 and 2, and 2 and 5?

My current code allows other messages between 1 and 2/3, but not
between 2/3 and 4/5. That doesn't seem quite right. The spec says:

: Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
: This message is sent with the old keys and algorithms. All messages
: sent after this message MUST use the new keys and algorithms.
: 
: When this message is received, the new keys and algorithms MUST be
: taken into use for receiving.
: 
: This message is the only valid message after key exchange, in
: addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE
: messages. The purpose of this message is to ensure that a party is
: able to respond with a disconnect message that the other party can
: understand if something goes wrong with the key exchange.
: Implementations MUST NOT accept any other messages after key
: exchange before receiving SSH_MSG_NEWKEYS.

It's not entirely clear what is meant by "after key exchange" in the
final paragraph above. My interpretation is "after KEX_DHINIT" (in the
stream from the client) and "after KEX_DHREPLY" (in the stream from
the server).

Another possible interpretation is that the only messages that can be
sent between KEXINIT and NEWKEYS are key-exchange messages and DEBUG,
DISCONNECT and IGNORE. Then all channels on the connection will freeze
completely during the entire key exchange process, which seems
undesirable, in particular with slow connections and machines. For
client-initiated key exchange, it's two roundtrips.

How do you handle this?

Regards,
/Niels