Re: Key Re-Exchange

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

I wrote:

> I also believe application data should be allowed during most of the
> key exchange. More precisely, at all times except
> 
>   1. Between a KEXINIT message and any guessed packed.
>   2. Between the final keyexchange message and NEWKEYS.

I have thought some more about this, and (2) is not quite consistent
with the way I'd like things to work.

The reason I want application data to be allowed is that I want an
implementation to be able to process events immediately when they
happen. For example, if I have some buffered data for some forwarded
socket, and then I happen to write some of it, I want to be able to
send a WINDOW_ADJUST message right away.

If messages like this can't be sent during key (re)exchange, I need
some extra packet queue besides my output buffer that contains raw
encrypted data, and to the user, the connection will appear to freeze
completely during the key exchange.

The restriction (1) causes no problem; if any guessed packet is to be
sent, it is known by the time the kexinit is sent, so it can be pushed
into the output buffer right away.

The restriction (2) works fine for the part sending the final
keyexchange message (for dh exchange, that's the server sending a
KEXDH_REPLY), at this time, session keys are known and NEWKEYS can be
sent right away. But it doesn't work for the client, whose last
keyexchange packet is KEXDH_INIT. When this is sent, session keys are
not yet known, so it doesn't make much senss to send NEWKEYS. Instead
the client must wait for the KEXDH_REPLY, and during that time, to
satisfy (2), any packets resulting from events on channels must be put
on hold.

This doesn't feel quite right. Is there any reason we can't relax (2),
and in general allow interleaving of keyexchange packets and other
packets?

/Niels