[noise] Key confirmation

[Michael Hamburg]

> On Oct 16, 2015, at 12:07 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> On Wed, Oct 14, 2015 at 6:43 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> 
>> 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
> [...]
>> 
>> 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
> 
> It's safe to send transport messages after sending or receiving the
> final handshake message.
> 
> Transport messages are based on the final keys from the handshake, so
> they are fully authenticated as coming from the other party.  The
> final payload in the final handshake message basically also has this
> property, but it's maybe simpler to ignore that, and only treat data
> as fully authenticated if it comes in transport messages.
> 
> I'll have to write up something about this, for now I've been busy
> with finishing the protocol / key derivation than user guidance.
> 
> Trevor

There’s one more wrinkle, though.  If the handshake is authenticating the initiator, then the responder doesn’t know if they’re talking to the right initiator.  They just know that nobody other than that party can decrypt the transport messages.  In some cases, that’s fine, but in other cases, the length of the transport messages (or their timing, or the willingness of the responder to say anything at all) can leak sensitive information.

— Mike