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

[Trevor Perrin]

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