[noise] Draft extension: Authentication of handshake data between messages

[str4d]

On 06/03/2018 08:09 PM, Trevor Perrin wrote:> Looking at your draft
text:  It might be more aligned with our
> existing tokens and modifiers if we allowed the "h" token to appear
> anywhere, and multiple times, even if the "h?" modifier was only able
> to place it at the end of messages.
> 
> Our current tokens have a lot of flexibility in how they can be
> arranged, even though we've named only a small set of these
> arrangements via pattern names and modifiers.

There are two kinds of flexibility in this particular case:

1) Flexibility in where the data is authenticated.
2) Flexibility in where the authenticated data is.

I believe 1) is what you are referring to: the "h" token that triggers
the requirement to pass the to-be-authenticated data to MixHash() should
be able to go anywhere.

If we want maximum flexibility in 1), it logically leads to
implementations requiring that the data to be authenticated needs to be
known by both parties before the call to WriteMessage() or ReadMessage()
that parses the "h" token (because there may be subsequent tokens in the
message pattern that need to call MixHash()). This inherently restricts
2), and in particular is incompatible with my use case:

- Read a fixed-length encrypted Noise message from the network.
- Call ReadMessage() to get the Noise plaintext.
- Extract a length field from the Noise plaintext.
- Read that many bytes from the network.
- Call AuthenticateData() with those bytes.

I don't yet see a clean way to define the "h" token that can handle both
1) and 2). To handle it fully, implementations would need to support
taking in arbitrary data to authenticate through the WriteMessage() and
ReadMessage() calls, _and_ to allow alternatively providing that data
via the AuthenticateData() call _if_ the "h" token is the last
MixHash()-dependent token in the message pattern. It ends up far messier
than for the "psk" token, which is fed entirely by data that both
parties know before the start of the handshake.

It's worth considering whether a token that triggers effects outside the
WriteMessage() and ReadMessage() state machines _should_ have as much
flexibility as other tokens. Maybe an appropriate solution here is to
have two "h"-like tokens: one that can be positioned anywhere but
requires the data up-front, and another that can only be positioned at
the end but can trigger higher-level state changes. I'm sure this is
getting into API design areas that other Noise contributors will have
opinions about :)

> 
> (We should probably also think more about potential use cases, and see
> if we want the modifier to be capable of more flexible token
> placement).

I guess a syntax for that would be something like h1t2, where the second
number defines the token within the message pattern that the "h" token
should go after. That would be a bit interesting to implement though,
both in terms of handling multiple "h" tokens in a message pattern, and
also defining modifier precedence (are the tokens the second number
refers to indexed before or after applying psk1?)

str4d

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180603/57b41ce2/attachment.sig>