[TLS] RFCs on weakened crypto are not fixed by warnings

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

As part of evaluating where defenses are needed, I often ask what I
would do if I were an attacker---including what I would do if I had a
massive budget to "covertly influence and/or overtly leverage" deployed
cryptography to make it "exploitable", and in particular to "influence
policies, standards and specification for commercial public key
technologies". In this mindset:

    * We're happy with non-hybrid PQ as attackers whenever there's a PQ
      security failure, whether a mathematical security failure as in
      SIKE etc. or an implementation security failure as in KyberSlash.

    * We're not so happy with ECC+PQ, since we then have to break ECC
      too. We can _sometimes_ do that---for example, because of yet
      another breakable NIST P-256 implementation, or because our new
      quantum computer is churning through thousands of ECC keys---but
      in the end we're breaking only a small percentage of the ECC keys.
      The fraction of ECC+PQ keys that we can break is substantially
      smaller than the fraction of non-hybrid PQ keys that we can break.

    * So: How can we covertly influence and/or overtly leverage
      cryptography to increase usage of non-hybrid PQ and decrease usage
      of ECC+PQ? Clearly an important step is to _normalize_ non-hybrid
      PQ, to have people thinking that non-hybrid PQ is acceptable.

    * For example, it'd be great to have an RFC on non-hybrid PQ. IETF
      puts a prominent claim of IETF "consensus" on every WG-issued RFC.
      People normally understand the issuance of the RFC as endorsement.

Switching to the defender's mindset, I conclude that an RFC allowing
non-hybrid PQ would be incurring security risks---and frivolously doing
so, since ECC+PQ has negligible extra cost.

Responding "the RFC doesn't say it's a standard" or "the RFC says it's
informational" or "there's a warning in the RFC saying don't use this"
is missing the point. These minor details might be noticed by some IETF
insiders but will do essentially nothing to stop the attack strategy.
The RFC will still claim to have IETF "consensus", will still be viewed
as endorsement, and will still help normalize non-hybrid PQ.

Viktor Dukhovni writes:
> I haven't seen any objections to publishing with caveats

Hmmm. Can you please clarify whether you've read through the objections
that were already filed?

I've read through. Even after neverending pointers from proponents to
the "Recommended: N" caveat in the spec, the most recent WGLC produced
22 people opposing publication as an RFC (vs. 21 people supporting an
RFC). See https://blog.cr.yp.to/20260405-votes.html for names, quotes,
and links for verification.

I _do_ see occasional requests for a much more strongly worded caveat
(e.g., "THE IETF RECOMMENDS TO USE draft-ietf-tls-ecdhe-mlkem IN ALL
CIRCUMSTANCES INSTEAD") but these requests have _almost_ zero overlap
with the statements of opposition.

The statements of opposition are much more commonly asking for the
document to be stopped (at least at this time). Stopping the document is
a much safer result than issuing the document with a caveat. See, e.g.,
the following quote: "Users will take the reputation of the IETF and
understand this as a recommendation, whether it says = N or not."

Procedurally, the chairs should be admitting the level of opposition and
removing this document from the WG pile, instead of shifting the burden
to opponents to state the opposition again and again and again.

I have three added notes here. First, my objection is not limited to the
proposal of non-hybrid ML-KEM in TLS; it also applies to, e.g., the
proposal to use non-hybrid ML-DSA in TLS. Forcing opponents to restate
objections for one document after another is particularly inappropriate
when the text of the objections obviously applies verbatim.

Second, my 2023 risk-assessment talk to the Federal Reserve TechLab gave
a median estimate of 2029 (sound familiar?) for _secret_ quantum attacks
breaking RSA-2048, a median estimate of 2032 for _public_ quantum
attacks breaking RSA-2048, and a specific caution about people failing
to account for improvements in quantum attack algorithms:

    https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf#page.10

So I'm baffled by claims that nobody was expecting improvements.

Third, obviously seeing quantum attacks coming didn't remove my support
for hybrids. Very much the contrary! It has been clear for a long time
that PQ deployment is begging for mistakes that make security worse;
hybrids are our best protection against that.

Yes, quantum computers are coming. Yes, they'll break _some_ ECC keys,
which is why we've been saying for years how important it is to add a PQ
layer (see, e.g., https://cr.yp.to/talks.html#2016.02.24 recommending
ECC+PQ). Even worse, sometimes the PQ layer fails---as it did for
CECPQ2b, which was used for tens of millions of user sessions. But
there's still a happy note in this disaster scenario: the best estimates
are that even large-scale quantum attackers won't be able to break more
than a small fraction of ECC keys. The quantitative attack costs matter.

Recklessly weakening CECPQ2b to non-hybrid SIKE would have meant giving
away _all_ of the tens of millions of CECPQ2b keys to low-cost attacks
as soon as the attacker figured out how to break SIKE, meaning 2022 at
the latest since that's when SIKE was publicly broken. The SIKE attack
is so cheap that it would scale up without trouble to trillions of keys.

Meanwhile actual CECPQ2b, hybrid ECC+SIKE, forces the attacker to also
break each ECC key, which currently looks much more expensive. The
impact of quantum attacks is limited not merely by the timeline of an
attacker having a quantum computer but also by the per-key attack cost.
Maybe continued improvements in (single or batch) quantum attacks will
make the cost of breaking vast arrays of ECC keys negligible at some
point, but maybe not; this is a much higher bar than a mere "CRQC".

Think ahead to 2029, and assume that the attacker has a quantum computer
at that point breaking _some_ of the CECPQ2b keys (by breaking the ECC
keys; the SIKE keys are already broken). Does this justify giving away
the rest of the keys to the attacker in 2029, or giving the keys away
today, or giving them away years ago? No, that would be stupid. But
using non-hybrid SIKE instead of CECPQ2b would have had the same effect.

Here are obvious questions to ask in response to any attempted argument
for non-hybrid PQ. SIKE attracted tremendous attention, survived a
decade of attack analysis (see https://eprint.iacr.org/2021/543) and
was proposed to NIST for standardization by a large team of experts; is
SIKE supposed to be an exception to the argument for non-hybrid PQ? What
exactly is the dividing line? Where's the evidence supporting this line?
Or is the argument that non-hybrid SIKE would have been a _good_ idea?

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