On Wednesday, 12 June 2024 02:02:41 CEST, D. J. Bernstein wrote:
There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.
I'm not sure I buy this premise. Currently there seems to be an
overwhelming convergence on ML-KEM768 for this job, with the one exception
being ML-KEM1024 being favored by the CNSA 2, but the latter also does not
recommend hybrids, leaving us with really only one choice for
the PQ hybrid
for at least the medium term.
Within ML-KEM, NSA isn't just favoring 1024, but _forbidding_ sizes
below 1024:
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF
The document doesn't forbid hybrids; on the contrary, it states that
"NSA may allow or require hybrid solutions due to protocol standards,
product availability, or interoperability requirements".
So there isn't a clear dividing line between what NSA is doing and what
the TLS WG will end up considering. Other people have already brought up
NSA's ML-KEM requirements in TLS discussions, and people who don't think
NSA should have control over IETF can still understand NSA's position as
communicating security concerns relevant to TLS decisions. This by
itself looks to me like a much more tricky discussion than any TLS curve
discussions!
while yes, the only people that will want ML-KEM-1024 are the ones that
will
want to follow CNSA 2.0, and those people are likely already following
CNSA 1.0 (or Common Criteria), so use P-384.
So, for the defined groups, if we provide P-256+ML-KEM-768 and
P-384+ML-KEM-1024 it should cover all the bases for FIPS and (likely even
future) Common Criteria requirements.
Apple has rolled out ML-KEM-1024 in another protocol:
https://security.apple.com/blog/imessage-pq3/
Meanwhile Meta says, regarding TLS, that they're rolling out ML-KEM-768
and, for performance reasons (TFO packet size), also ML-KEM-512:
https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/
Sounds like big deployments of all three ML-KEM sizes already (times
different Kyber versions, but let's assume all the different versions
switch to the final version of ML-KEM after NIST posts that, which
should happen any day now), and at least some of the underlying
rationales are certainly applicable to TLS.
yes, the question is if we want to pair P-256 with ML-KEM-512 or with
ML-KEM-768 for the "FIPS compatible fast option" hybrid key exchange group.
I don't have a strong opinion either way.
--
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
