> > 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! 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. As for the patent problem, one can _hope_ that Yunlei Zhao is wrong in writing "Kyber is covered by our patents" in https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ but I haven't seen any public analysis of, e.g., their patent https://patents.google.com/patent/CN107566121A/en concluding that Kyber _isn't_ actually covered, never mind the question of how convincing such a public analysis would be. This is just one example of the patent minefield. > If the only reason for revisiting the current choices in recommended curves > is an expected large number of PQ options (or even just more than one PQ > option), it might make sense to have that discussion first. The PQ security issues, performance issues, further software issues, and patent issues look much more complicated than the curve issues, and include various issues that I'd expect to be resolved in CFRG. It's clear that a big wave of specific PQ proposals is coming to the TLS WG soon; this doesn't mean the wave is here yet, beyond some initial work such as draft-ietf-tls-hybrid-design. The curve situation is different. There's lots of experience now with the interactions between curve choices and TLS software (and hardware). The TLS WG doesn't have curve questions for CFRG. So the TLS WG can settle now what it's going to look for on the curve side of PQ hybrids. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
