[noise] Negotiation and 0-RTT

Alexey Ermishkin scratch.net at gmail.com
Thu Jul 6 19:44:24 PDT 2017

Exactly what I was going to suggest!

This looks simpler and yes, we as an App would probably better know how server handles different versions

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Friday, July 7, 2017 3:52 AM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Negotiation and 0-RTT

On Thu, Jul 6, 2017 at 6:39 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Thu, Jul 6, 2017 at 8:55 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>> Is it possible we'll use 0-RTT with just another client_version? So that we would not have to send messages in parallel.
> One issue is that I was thinking of using the initial cleartext 
> payload to contain any version advertisements about what other 
> versions are supported.  So if we do IK in parallel with XX, the XX 
> initial cleartext payload can still be used for that, and we can 
> fallback to XX if IK isn't decryptable:
> Message 1:
>  -> version for XX
>  -> initial_message = XX, with cleartext version advertisements  -> 
> zerortt_message = IK
> If we just send an initial IK message for 0-RTT, we don't have that 
> advertisement space (or we'd have to do something different):
> Message 1:
>  -> version for IK
>  -> initial_message = IK

I guess we should consider the "something different" option more.  We could remove the negotiation data from the initial cleartext payload and put it in a separate block, then just hash it into the prologue:

Message1 header:
 - 4 bytes: client_version
 - 2 bytes: negotiation_len
 - " bytes: negotation_data
 - 2 bytes: noise_message_len
 - " bytes: noise_message

Message2 header:
 - 4 bytes: server_version
 - 2 bytes: noise_message_len
 - " bytes: noise_message

Other headers:
 - 2 bytes: noise_message_len
 - " bytes: noise_message

This allows us to send negotiation data whether the initial message has a cleartext payload (XX) or 0-RTT encrypted payload (IK).

This downside is that it's not as easy to send a different Noise initial message alongside a 0-RTT Noise message.  For example, suppose you send an IK message with a version that the server doesn't recognize.  If there's an XX message in parallel with an older version, the server can easily ignore the IK and just use the parallel XX message.

OTOH, if you're sending an IK message you should have a good idea that the server will recognize this version and be able to do a fallback protocol based on it.  So maybe that's not a major problem?

The logic here seems simpler:
 - Client chooses an initial Noise protocol
 - Client's first message includes an initial Noise message, a version identifying the initial Noise protocol, and arbitrary "negotiation data" which the server could use to choose a different Noise protocol.
 - If the server likes the client's initial Noise protocol, the server returns server_version == client_version.
 - If the server doesn't like the client's initial Noise protocol, the server returns a different server_version, and a fallback protocol is performed, with the first message hashed into the fallback protocol's prologue.

So is this better or worse than supporting 0-RTT with 2 parallel Noise messages?


More information about the Noise mailing list