On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:
Andrei Popov writes:
I support this change, willing to implement it in the Windows TLS
stack. We have thousands of customers concerned about increased
latencies due to the enablement of TLS 1.3. The services they connect
to require NIST curves and HRR is required to get TLS clients to send
appropriate key shares.
To clarify, when you say "require NIST curves", do you mean "require
conformance with NIST SP 800-56A"?
really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.
In other words, will another curve be allowed once it's added to NIST
SP 800-56A? Maybe faster: would the short-term problem be addressed if
we can convince NIST to announce that it will consider X25519 and X448
for a revision of SP 800-56A, and doesn't intend to enforce conformance
of cryptographic modules with SP 800-56A until the revisions are done?
Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.
Or are you saying that, independently of NIST's decisions, the services
in question are for some reason specifically requiring what's typically
called the "NIST curves", namely the fifteen NSA curves that NIST
standardized? Or the subset of those that NIST hasn't deprecated yet?
Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.).
Similarly
Common Criteria certifications, while they're international, they're
similarly
heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.
And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.
So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
and
P-384).
--
Regards,
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
