On Sun, Sep 8, 2024, 9:41 AM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote:
> 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. > Yes: several embedded stacks and browsers had issues in 2014. I know because I found the issues. > > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
