[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