[noise] Transport protocol spec finalizing
scratch.net at gmail.com
Fri Jul 14 01:56:39 PDT 2017
Yep, totally agree
From: Trevor Perrin [mailto:trevp at trevp.net]
Sent: Friday, July 14, 2017 1:38 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Transport protocol spec finalizing
On Fri, Jul 14, 2017 at 8:11 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> 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,
> /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?
Should we remove the version field?
For handshake messages after ClientHello, the rules could be:
If noise_message is non-empty:
- If negotiation_data is empty, the sender accepted the previous Noise protocol
- If negotiation_data is non-empty, the sender has switched to a different Noise protocol
If noise_message is empty:
- The sender is rejecting the previous Noise protocol, and can send error or retry data in the negotiation_data. The sender may leave the connection open so the recipient can try again.
(Of course, you could add your own version field or enums etc in negotiation_data).
More information about the Noise