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

[Trevor Perrin]

On Fri, Jun 22, 2018 at 6:27 AM, Karthikeyan Bhargavan
<karthik.bhargavan at gmail.com> wrote:
> Hi Trevor,
>
> Re-reading other parts of the spec, authentication goal 1 explicitly speaks about “ss”, so this may need to change as well,
> if we decide we want to forbid patterns that rely on “ss” for authentication (which I think is good general advice, but perhaps too strong a restriction.)

We do rely on "ss" for sender-authentication in K and X, and in the
first message of KK and IK (0-RTT).  There's no ephemeral that could
be used for sender-authentication there, so this is the best we can
do.


>> You mention a couple alternatives:  One was "validating" public keys.
>> It's not clear what you mean, validating EC public keys has
>> historically meant different things, some of them expensive, and this
>> ambiguity has caused problems [1].  In particular, Noise is most
>> commonly used with X25519 (previously Curve25519), for which
>> widespread software and specs exist that don't apply any of the checks
>> you might ask for, and which advertise the simplicity of this API as a
>> virtue.
>
> I agree that there has been a lot of confusion about this, even for X25519.
> I was speaking of an is_on_curve check which is typically less expensive
> than scalar multiplication, but yes, can be difficult to implement for some coordinate systems.

You probably mean something different, an "on curve" check doesn't
prevent subgroup confinement of the output to a small range of values,
which is the probably the relevant property for replay attacks.  If
you're considering identity-binding/UKS then you might want a stronger
(and more costly) check that public keys generate the correct
subgroup, to prevent equivalent public keys.


> A question worth asking is what if someone uses Noise with P-256?
> In that case, they do need to perform key validation or else may be vulnerable to invalid curve attacks, right?
> It may be good to warn about this in the security considerations.


The requirements on the DH are in Section 4.1:

"""
The public_key either encodes some value in a large prime-order group
(which may have multiple equivalent encodings), or is an invalid
value. Implementations must handle invalid public keys either by
returning some output which is purely a function of the public key and
does not depend on the private key, or by signaling an error to the
caller. The DH function may define more specific rules for handling
invalid values.
"""

An off-curve P-256 "public key" would be an "invalid value", thus
would have to result in an error in DH(), or return an output which is
"purely a function of the public key and does not depend on the
private key", e.g. all-zeros.

The hope is that this definition is broad enough to cover existing
implementations of Curve2559/X25519 as well P-256, finite-field DH,
etc.


>>> Your (3) proposal was to randomize the calculation by using ephemeral
>>> public keys as nonces.  We do this if PSKs are involved, since we want
>>> PSK protocols to be secure even if all the DHs are bad.  But since
>>> we've already decided to force people to do ephemeral-static DH, this
>>> would just add unnecessary calculation to pure-DH protocols.
>
> Indeed, I do think of “ss” as a way of computing a PSK from static DH keys.
> In that sense, any protections we provide for PSK patterns should be inherited
> by pure “ss” patterns (unless we forbid pure “ss” protocols, as you indicate.)


Not sure if a pure-ss protocol is something with only a static-static
DH, or also a "Unified Model" mixing static-static and
ephemeral-ephemeral DHs.

In any case, Noise doesn't support either, and insists that you use
ephemeral-static DH for authentication when you can.

Trevor