Hi, D. J. Bernstein wrote: > recent breaks of "5G Subscription Concealed Identifiers"
The paper broke a hobby implementation of 5G which in addition to ignoring the mandatory point validation also ignored the mandatory point compression. The implementation is not used in any 5G network and would not interop with any compliant implementation. That said, I agree that implementations not doing point validation is a major problem. To quote NIST: "Cryptographic standards and guidelines should be chosen to minimize the demands on users and implementers as well as the adverse consequences of human mistakes and equipment failures". I agree that NIST should allow X25519 and X448. Elliptic curve cryptography will be used for a long time. Both in hybrids, but also in contrained radio systems where ML-KEM is too big or NIKE is required. My company will use EdDSA in hybrid with ML-DSA. Not because ECDSA is bad, but because EdDSA is better. D. J. Bernstein wrote: >we should be evaluating MTI choices for their real-world security impact Dan, do you have any concrete example of TLS implementations using P-256 without point validation? Otherwise the discussion is a bit to general for TLS. Cheers, John From: D. J. Bernstein <d...@cr.yp.to> Date: Sunday, 8 September 2024 at 13:23 To: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360 Eric Rescorla writes: > I do not think we need to make Curve25519 MTI. The purpose of MTIs is to > provide a minimum baseline for interoperability, and we have that already > with the existing MTI. That's entirely compatible with most people > preferring X25519 because they believe it's better than the MTI. As the list in Appendix A of https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23safecurves&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039116785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Vz6i0fGqyBcFluh8hzLvBp%2BGamSy4iABNnITqyrkjj4%3D&reserved=0<https://cr.yp.to/papers.html#safecurves> shows, the NSA/NIST standards for the core tasks of ECDH and signatures keep triggering security failures, for reasons that two of us correctly predicted many years ago. One can't expect new implementors to figure out these security issues if they aren't warned. As for "believe", in some cases we have direct security comparisons: the "Minerva" attacks and the recent breaks of "5G Subscription Concealed Identifiers" worked against implementations of the NSA/NIST standards while failing against implementations of X25519/Ed25519 in the same software. More broadly, these NSA/NIST security failures keep happening, even in major ECC implementations: see, e.g., Firefox's announcement "CVE-2023-6135: NSS susceptible to 'Minerva' attack". In general, we should be evaluating MTI choices for their real-world security impact, not just whether they're sufficient to guarantee interoperability. What would be best for security is to transition away from the NSA/NIST approach---as most TLS connections have already done for encryption. The first step in ensuring interoperability for such a transition is to add another MTI. ---D. J. Bernstein P.S. People who need FIPS certification should be asking NIST to follow through on allowing X25519. NIST said in https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20200810165057%2Fhttps%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcryptographic-module-validation-program%2Fnotices&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039125481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RXQwxEVUOqhy1V4h9DTkFhEtNByzTn6rCOuRiWdOaT4%3D&reserved=0<https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices> that it would add Curve25519 and Curve448, that X25519 and X448 "will be considered for inclusion in a subsequent revision to SP 800-56A", and that "CMVP does not intend to enforce compliance with SP 800-56A until these revisions are complete". NIST did finally manage to add Ed25519 last year, so progress is possible. In any event, IETF shouldn't be allowing NIST to control IETF's cryptographic choices. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
