[noise] Negotiation and 0-RTT

[Trevor Perrin]

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?

Trevor