[noise] Potential forgery attack on "ee, ss" patterns

[Karthikeyan Bhargavan]

Trevor,

I think we’re agreeing that the text in validity rule 3 of 7.1 may need some fixing but the precise conditions this rule intends to enforce on patterns is the following
(I have broken it into 4 parts for my own understanding):

a) If the initiator 	encrypts data after processing an ss token, it must have also processed an es token
b) If the responder 	encrypts data after processing an ss token, it must have also processed an se token
c) If the initiator 	encrypts data after processing an se token, it must have also processed an ee token
d) If the responder 	encrypts data after processing an es token, it must have also processed an ee token

Is the above correct? This seems like a sensible set of rules that captures Noise’s implicit design pattern and I’d be happy to see it written more clearly in the spec.

Let me explain, just one last time before we move on, why the current text does not enforce the above rules.
It is not a big deal, since writing down logical rules in readable text often leads to such ambiguities, but understanding it may guide us on how to fix the text:

> After performing a DH between a remote public key (some remote e or remote s)  And any local key that is not the ephemeral private key (some local s), the local party must not call ENCRYPT() unless it has also performed a DH between the ephemeral private key (some local e) and the remote public key (the same remote e or remote s).

This text reads as:
a') If the initiator 	encrypts data after processing an ss or se token, it must have also processed an es or ee token
b') If the responder 	encrypts data after processing an ss or se token, it must have also processed an es or ee token

Note the disjunction on the left and the right which collapses our four rules into two but allows more patterns.
This means that the message pattern: “e, ee, s, ss" would be allowed (without any es,se tokens), and so would the pattern: “e, s, es, se” (without any ee tokens).
It will be great to remove this ambiguity.

Now, although I understand why Noise would want to enforce this validity rule (using ss only in combination with es/se) and it is fine to keep the current design.
However, it is also worth noting that an alternative handshake processing and pattern validity rule could make things uniform for DH and PSK patterns and allow more safe patterns.
For example:
====
Handshake Token Processing (for all handshakes — both PSK and non-PSK):
- In all handshakes, the "e" token in a pre-message pattern or message pattern always results in a call to MixHash(e.public_key), followed by MixKey(e.public_key).

Validity Rule 3 (for all handshakes — both PSK and non-PSK)::
- A party may not send any encrypted data after it processes an authenticating token (“psk” or “es” or “se” or “ss”) unless it has previously sent an ephemeral public key (an "e" token),
  either before or after the authenticating token.
====

I hope this discussion helps people interested in understanding Noise.
We’ll continue bashing at various valid/invalid noise patterns.

Best regards,
Karthik






> On 22 Jun 2018, at 08:56, Trevor Perrin <trevp at trevp.net> wrote:
> 
> On Fri, Jun 22, 2018 at 5:20 AM, Karthikeyan Bhargavan
> <karthik.bhargavan at gmail.com> wrote:
>> Hi Trevor,
>> 
>> 
>>> That pattern is invalid per bullet 3 of 7.1:
>>> 
>>> http://noiseprotocol.org/noise.html
>>> """
>>> 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.
>>> “""
>> 
>> Aha! We misinterpreted the intention syntactic rule and so our pattern was accepted by noise explorer.
>> It hinges on the definition of “remote public key”.
>> 
>> One reading of this rule would be the following:
>> After performing a DH between a remote public key (some remote e or remote s)  And any local key that is not the ephemeral private key (some local s), the local party must not call ENCRYPT() unless it has also performed a DH between the ephemeral private key (some local e) and the remote public key (the same remote e or remote s).
> 
> I think this reading just adds a few parenthesized clarifications, and
> changes the phrasing "local private key" to "local key".  So it seems
> correct.
> 
> 
>> Under the above interpretation the pattern KXS I showed you is valid, right?
> 
> No, I don't think so.  The responder encrypts the response payload,
> but the responder has performed a DH between the remote s and the
> local s, without performing a DH between the remote s and the local e.
> 
> 
>> Maybe by “remote public key” you meant to say “remote static key”? If so, this rule would not apply to all patterns, so I wonder if more word smithing is required here.
> 
> I don't understand that question.  The rule applies to either remote
> static keys or ephemeral keys.  We just say "public" and "private"
> because DH involves the remote party's public key and the local
> private key.
> 
> I agree we need to wordsmith some more and spell this out better.
> 
> 
>> In any case, you are right that it does not have the same security as KX:  the authentication level is 1, and the confidentiality level is “5” or something.
> 
> Not 5, since that requires "strong forward secrecy".  (FYI: In the
> current draft for revision 34 we're considering renaming these
> properties to "source" and "destination" properties, since Noise
> Explorer team brought up that calling them "authentication" and
> "confidentiality" was confusing).
> 
> 
>> Still it is “good enough” to send messages if the responder does not care about KCI and is happy with weak PFS, right?
> 
> Well, it's good enough for NIST, I think this is roughly "Unified
> Model" in SP800-56A.  But Noise cares about KCI / weak PFS, so doesn't
> let you do this.
> 
> This is an opinionated stance on Noise's part.  We haven't discussed
> it in awhile so it may be surprising to people, and worth more
> discussion.  I think alternatives would mean adding complexity so that
> people can build worse protocols, but happy to debate / explore that
> further.
> 
> 
>>> So this is another reason for the validity rule:  Noise forces people
>>> to to use ephemeral-static DH for authentication, not static-static,
>>> because ephemeral-static DH provides better security in case the
>>> static keys are compromised.  The "ss" token is used in current
>>> patterns when there's no other option for authentication (e.g. 0-RTT),
>>> and could also be used for resistance to ephemeral-key compromise, but
>>> we've otherwise taken an opinionated stance against relying on "ss”.
>> 
>> This opinion was not obvious from the spec and should probably be made more explicit?
> 
> Yeah, we definitely need a rationale section for this.
> 
> 
>> It is otherwise not obvious to the reader why Noise would allow unauthenticated patterns like NN but not allow weakly authenticated patterns like KXS.
> 
> If there aren't static public keys then NN is the best you can do.  If
> there are static public keys, then ephemeral-static DH is the best you
> can do for authentication, so Noise forces that.
> 
> Trevor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180622/d921be4a/attachment.sig>