[noise] Noise Explorer

[Trevor Perrin]

On Tue, Aug 21, 2018 at 9:08 AM, Nadim Kobeissi <nadim at symbolic.software> wrote:
> Hello everyone,
> A Noise Explorer paper now exists:
> https://eprint.iacr.org/2018/766


Very nice, few bits of feedback:


Section 2: The example of pre-messages isn't great: "could be used in
secure messaging protocols, where prior knowledge of an ephemeral...".
It's not clear what "secure messaging" means in this context, and we
mostly use pre-messages with static keys, not ephemeral keys, except
for the fallback case.

Better examples would probably be "one-shot" protocols like public-key
encryption to a static key, or 0-RTT handshakes where the static key
was cached or was looked up via some directory.


Section 2: The validity rules listed here omit a crucial validity rule
which has been in the spec for a long time.  (The paper then
re-invents that rule as a proposal in Section 5.2, so I'll say more
about that below).


Section 2: The footnote 2 isn't correct as of revision 34.  It's not
clear whether this paper intends to reference revision 33 or 34, it
seems to switch back and forth.


Section 2.3: We renamed the security-property grades to "initiator"
and "responder in revision 34, in response to discussions with Noise
Explorer team.


Section 2.3: the properties introduced in your new "authentication"
grades 3 and 4 are already covered by the existing "responder" (or
"confidentiality" grades), which is why I think these are redundant
and shouldn't be introduced.


Section 2.4:  The deferred patterns only defer DH operations, not "the
communication of public keys".

Figure 7:  Surprised me a bit that the WireGuard pattern (IKpsk2) isn't listed.

Section 5.2:  This section claims to "discover a novel forgery attack
within certain Noise handshake patterns".  However the example is an
invalid Noise handshake pattern, so this isn't an attack against
Noise.  Also, I wouldn't call this a novel discovery, since we had
anticipated it and had a rule to prevent it.

In revision 33, the validity rule that disallows this pattern was
unambiguous, if terse:

"After performing a DH between a remote public key and any local private
key that is not the ephemeral private key, the local party must not call
ENCRYPT() unless it has also performed a DH between the ephemeral
private key and the remote public key."

This rule was intended to prevent the scenario you describe:  the
victim using a DH output like ss without randomizing it via an
ephemeral-static DH with your partner's static.

Anyways, the paper proposes that a "A Noise Handshake Pattern
validation rule could be introduced to disallow the usage of ss in a
handshake unless it is accompanied by se of es in the same handshake
pattern."

This rule existed!  The paper goes on to talk about a "lack of clarity
in the then-current revision", and that "As a result of our report,
revision 34 of the Noise Protocol Framework specification included the
following more stringent pattern validity rule. [...]  These new
validity rules [...]".

I disagree with that history: The validity rule didn't change.
However, since your team had seemingly missed and then mis-read the
existing rule, and since it lacked a good rationale, I added more
descriptive text, and spelled it out specifically for static keys (I
had written it more generally initially, to allow for different types
of keys in the future, like semi-static or something).

Aside from that, I quite like the paper, it could use some polish and
proofreading, but I look forward to the final version!

Trevor