[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360

["D. J. Bernstein" <[e-mail]>]

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.