[noise] Transport protocol spec finalizing
Trevor Perrin
trevp at trevp.net
Thu Jul 13 10:38:29 PDT 2017
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
More information about the Noise
mailing list