[noise] Key confirmation

[Jason A. Donenfeld]

Hi folks,

This topic has come up a few times. There are two-message handshakes,
such as Noise_IS, that look like this:

1. Initiator ---->---handshake message--->---> Responder
2. Responder ---->---handshake message--->---> Initiator

The KEA+ paper, among others, states that two message handshakes can't
be secure under various notions of security, and so they propose a
variant -- KEA+C -- that involves an additional confirmation message.
When I've asked on this list about it prior, the answer was that the
first _transport_ message that the initiator sends to the responder
doubles as a key confirmation message. Thus, the full sequence is:

1. Initiator ---->---handshake message--->---> Responder
2. Responder ---->---handshake message--->---> Initiator
3A. Initiator ---->---transport message--->---> Responder

After step 1, nobody knows anything.
After step 2, the initiator has received confirmation from the responder.
After step 3A, the responder has received confirmation from the initiator.

This is, at least, how I interpreted prior discussions on this. (There
was some mention of thoughts about this being added to the "security
considerations" part of the spec, IIRC.)

What I'm wondering about in this email is whether or not the following
should be allowed:

1. Initiator ---->---handshake message--->---> Responder
2. Responder ---->---handshake message--->---> Initiator
3B. Responder ---->---transport message--->---> Initiator

In other words, is it safe for the responder to send a transport
message (3A), before he receives the transport confirmation message as
in 3A above? Should implementations prevent 3B from being sent until
3A is received?

Thanks,
Jason


[ As a sidebar, my implementation may wind up having this restriction
regardless of the security discussion. The reason for this is that
handshake messages are processed asynchronously, since they're more
computationally expensive. Having such a restriction prevents against
the case in which  the initiator may have received message 2 above,
but not yet processed it, when along comes 3B, for which no decryption
key has yet been derived. ]