On Monday, 9 September 2024 08:44:46 CEST, D. J. Bernstein wrote:
John Mattsson writes:
ignoring the mandatory point validation
Exactly! That's how the real world works. The NSA/NIST approach fills
ECDH and signatures with traps for the implementors; implementors fall
into the traps; the NSA/NIST responses sound like "This security failure
is _your_ fault! Read Section 5.6.2.2.2.X.Y.Z.Z.Y of the documentation!"
Actual quote: "NIST is not aware of any vulnerabilities to attacks on
these curves when they are implemented correctly and used as described
in NIST standards and guidelines." Similar earlier quote from NSA: "We
are unaware of any weaknesses in the DSS or in the DES when properly
implemented and used for the purposes for which they both are designed."
It's much more robust to tell implementors "Use X25519" and "Use
Ed25519". We have a detailed analysis of how this reduces security
risks. We also have real-world security observations following the
predicted patterns. Of course, adding X25519 as MTI is just one step
towards telling people not to touch the NSA-supplied footgun, but it's
better than saying "Everything is fine, no action needed".
Dan, do you have any concrete example of TLS implementations using
P-256 without point validation?
Yes. I already pointed to the list of security failures in Appendix A of
https://cr.yp.to/papers.html#safecurves; some of the failures listed
there are point-validation failures in TLS implementations.
Furthermore, some of the other examples in the list are security
failures in TLS implementations other than point-validation failures.
See, e.g., the Firefox "CVE-2023-6135: NSS susceptible to 'Minerva'
attack" announcement that I mentioned before.
Does anyone know whether NIST claims that the NSA/NIST curves weren't
"implemented correctly" in Firefox? Or that CVE-2023-6135 wasn't a
vulnerability? Has there been _any_ response? "Everything is fine"?
It's not as if people implementing NSA/NIST curves for TLS are in some
radically different situation from people implementing NSA/NIST curves
for other environments. The full spectrum of implementation failures is
a bunch of dead canaries in the coal mine; asking "Did any miners die
yet?" is the wrong question. We should be proactive about security.
To clarify the Firefox situation a bit: what George, my coworker, have
showed, is only that the nonce selection and scalar point multiplication
in NSS is not constant time with P-256 curve. We haven't actually performed
an attack in which we extracted the private key.
We haven't done the same for Ed25519 because we haven't tested Ed25519 or
X25519.
In practice, what we've shown is that the implementation is _likely_
vulnerable to microarchitectural side-channel attacks.
And I'm pretty sure that the implementation of Ed25519 in
https://github.com/tlsfuzzer/python-ecdsa is also vulnerable to the
same class of attacks because of the super-leaky implementation of
arbitrary precision arithmetic it's using.
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
