[noise] Transport protocol spec finalizing

[Alexey Ermishkin]

Yes, that's seems legit.

However I'd like to talk about the term "server_version != client_version"

If we use negotiation_data, we might put all necessary info into it and use version as, well, version. 

For example if we wanted to support a broader range of available options, suggested by NoiseC, 
https://github.com/rweather/noise-c/blob/master/include/noise/protocol/constants.h 
we would have to put 5 or 6 enums into 4 byte version and I guess the number will only increase over time.

So, would it be more correct to say that the way server is able to switch to another protocol is not only by changing version but also by supplying an additional negotiation_data without having to change the version?

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Thursday, July 13, 2017 10:38 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Transport protocol spec finalizing

On Thu, Jul 13, 2017 at 11:07 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> I thought of it a little bit more and looks like we cannot legally use negotiation_data in the second and third messages until Noise will specify a mechanism of hashing additional data into the handshake state. So for v1 we will fix them to 2 zero bytes. An exception will be done for case when server_version != client_version, then the negotiation_data from the second message goes into the new prologue.


Right, negotiation_data would have to be empty if version matches the previous version.  This signals that the previous Noise protocol is continuing, so there's no way to mix the negotiation_data in.

You're right that we could change this by adding a new modifier and token that adds new MixHash steps for negotiation_data.  For example:

Noise_XX+h2+h3:
 -> e
 <- h, e, ee, s, es
 -> h, s, se

The `h` tokens here would symbolize the new MixHash steps.

I'm not sure we're planning to do this, though.  At least, I think we should try to live within the current limits, first.


So I think the generalized rules would be:

For handshake messages after ClientHello:
 * If version == prev_version, negotiation_data must be empty
 * If version == 0xFFFFFFFF, noise_message must be empty, and the sender is allowed to keep the connection open in case the recipient wants to send a new initial message, using as prologue the entire handshake transcript until that point.
 * Otherwise (version != prev_version or 0xFFFFFFFF), negotiation_data may be non-empty, and the sender is allowed to send a noise_message, which is understood as a new initial message whose prologue includes the entire handshake transcript until this point.



Trevor