[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Hi Uri,


I think it’s good that you point out that the classic component offers no protection against the “record now, decrypt later” threat. However, your conclusion that “The only use case when hybrid adds anything meaningful is if your data’s value is short-lived” is not correct. The classic component in hybrids can provide significant short-term value against theoretical attacks, side-channel attacks, and implementation bugs in the PQC component, regardless of the data’s lifetime.

My point was/is — if the data requires protection beyond CRQC, then it matters less when it is compromised during the period of its lifetime.


Yes, of course, for the next few years Classic would likely stand. My point, however, is — the long-term safety of the sensitive data relies solely on the PQ part. And that’s the main point of CNSA-2.0.

There are good reasons why using multiple independent layers of protection is standard in high-security systems. 


Yes, of course.


For example, the NSA’s CSfC program states that a “solution uses two nested, independent tunnels to protect the confidentiality and integrity of data” [1]. 


You don’t think CSfC allows mixing “long-term” components with those “likely to survive for the next few years”? Their two-stacks solution is exactly about independent implementations, likely of the same algorithm(s), with the purpose of avoiding breakage through exploitable implementation bugs. Nothing in common with the “hybrid hysteria” that I’m observing here.


In my view, Bernstein et al. are too focused on the algorithmic aspects of security protocols. When using a security protocol, for example, TLS, there are many potential vulnerabilities in other parts, such as the code or the protocol specification. 


Yes!


If you truly want high security, you should follow the NSA’s guidance and use two nested, independent tunnels, preferably employing different protocols, different algorithms, and implementations by different teams.


We appear to understand this NSA guidance differently. Nowhere did I see “different protocols” or “different algorithms”. And absolutely — “by different teams” (actually, by different vendors ) is a hard explicit non-negotiable requirement.


TNX

Cheers,
John

[1] https://www.nsa.gov/resources/commercial-solutions-for-classified-program/customer-handbook/?utm_source=chatgpt.com <color: rgb(150, 96, 125); margin-top: 0px; margin-bottom: 0px;> 


From: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Date: Friday, 20 February 2026 at 06:26
To: Izzy Grosof <[e-mail]>, [e-mail] <[e-mail]>
Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)


> I would like to register my strong objection to this working group promoting 
> the use of non-hybrid ML-KEM in any way, or any other non-hybrid
> post-quantum cryptosystem. 


I would like to register my strong disagreement with the above position. And register support for allowing the use of “pure”, aka non-hybrid ML-KEM (and other non-hybrid PQ cryptosystems).


Among the reasons — since the goal of PQC is protecting data with long-term value — protection given by the Classic part of the hybrid is meaningless against the threat of “Record Now, Decrypt Later”. Confidentiality of the recorded-now sensitive data relies solely on the PQ part of the hybrid.


The only use case when hybrid adds anything meaningful, is if your data value is short-lived, so it is not likely to be exposed to CRQC — so, Classic alone would suffice, and adding PQ KEM doesn’t hurt.


The only situation when hybrid could make sense for a "long-term” data is if:



1. Crypto-Relevant Quantum Computer does not materialize; and
2. PQ algorithm falls to a Classic attack; and
3. Classic algorithm remains unbroken.



> The correct course of action is to recommend against such an ill-advised decision,


That’s a matter of opinion. I consider your recommendation ill-advised, for reasons stated above.


> The performance improvements of a non-hybrid approach are trifling;


Correct. Though this depends on the use case — some would welcome the speedup of Lattice-based crypto over ECC.
But this is not about the extra computations required for hybrid.


> the security risks are immense,


Simply not true. See above. The logic above is straightforward enough.


Also, this might be instructive:


System
Proposed
Standardized
Lag-to-Standardization
Math-Studied-For-How-Long
RSA
1977
~1993–1995
~15–20 years
Number theory: 2000+ years
ECC
1985
~1998–2000
~13–15 years
Elliptic curves: ~150 years
Lattice crypto
1996
2022–2024
~25 years
Lattices: ~150–200 years
McEliece 1978 2024 ~46 years Codes: ~60-75 years


> given the breadth of attempted post-quantum cryptosystems that have fallen to classical attacks;


Given the number of standardized successful post-quantum crypto systems that stand strong, we shouldn’t panic needlessly.


> I am baffled that so many people are taking a stand in favor of a non-hybrid system, which is transparently unwise.


Well, “wisdom" apparently is a relative term, because to me the position you’re advocating seems unwise.


> For context, cryptography is not my area of research


Coincidentally, it is mine. Plus, a few decades of experience (and some publications & patents, nothing earth-shattering).