John Mattsson writes: > https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/
The claim at hand was that "ML-KEM-512 is the only adopted quantum-resistant algorithm that can be used to bypass legacy middle boxes". There was a request for evidence. Now we're given this link as an answer. But the linked article doesn't claim that ML-KEM-512 bypasses legacy middle boxes! More broadly, it doesn't claim that ML-KEM-512 produces a deployability improvement. The article merely says that it's using ML-KEM-512 to _save an RTT_ in a particular context. Furthermore, there are a bunch of other ways to save the same RTT without switching to this bleeding-edge size. The article even mentions a few ways. So this is a remarkably weak argument for ML-KEM-512. > https://blog.cloudflare.com/pq-2025/ That article does say "a small but significant fraction of clients experienced broken connections with NTRU-HRSS"---but that's describing observations from 2019, before fixes were broadly rolled out! Private discussions back then gave me the impression that the single-packet limit was only one of many observed limits, but at this point I don't see any reason to try to dig up the obsolete details. The same article continues: "Chrome did a great job reaching out to vendors whose products were incompatible. If it were not for these compatibility issues, we would've likely seen Chrome ramp up post-quantum key agreement five years earlier. It took until March 2024 before Chrome felt comfortable enough to enable post-quantum key agreement by default on Desktop. After that many other clients, and all major browsers, have joined Chrome in enabling post-quantum key agreement by default." > https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-07.html How is this link supposed to justify the claim that "ML-KEM-512 is the only adopted quantum-resistant algorithm that can be used to bypass legacy middle boxes"? I see where it says that multiple packets cause "potential delays", but this again is just a minor efficiency issue. It's important to avoid conflating cost reduction with deployability. As a reminder, the TLS WG charter has "improve security" as a goal; it includes "deployability" as a goal (Transport Layer Security isn't living up to its name if it can't be deployed); but it does _not_ have cost reduction per se as a goal. Allowing PQ as an option beyond ECC+PQ and switching to bleeding-edge ML-KEM-512 are perfect examples of cost reductions that _don't_ improve deployability. Some more specific types of cost reductions are within charter, such as "protocol changes that reduce TLS resource consumption without affecting security" and "extensions that help reduce TLS handshake size", but what we're talking about here affects security and isn't an extension. ---D. J. Bernstein ===== NOTICES ===== This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. (That sentence is the official language from IETF's "Legend Instructions" for the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC". I'm fine with redistribution of copies of this document; the issue is with modification. Legend language also appears in, e.g., RFC 5831. For further background on the relevant IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.) _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
