[TLS] Deployability claims

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

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.)