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://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://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
