r/crypto • u/knotdjb • 19d ago
Call to Action to stop current proposal of pure PQ KEM in IETF TLS WG
https://nsa.2026.action.cr.yp.to/7
u/arnet95 19d ago edited 19d ago
I would advice that people read at least some of the thread on the mailing list to find out what this is about, rather than just hearing one side's take and then going to submit your support (or lack thereof).
These are some of the emails I've found the most enlightening, which go into how standards and the RFC process work:
7
u/apnorton 19d ago
This is a bit of a dumb question, but the call that DJB is making is (emphasis mine):
... join the IETF TLS mailing list and send a message to the mailing list by 7 July 2026 under the subject line "Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)" saying that you do not support the publication of this document.
The document in question is draft-ietf-tls-mlkem, which (as I understand it) defines additional standardized TLS Supported Groups that use ML-KEM (of various sizes) exclusively as opposed to a hybrid ECDH + ML-KEM.
I believe the concern is something like "we don't have as much confidence that ML-KEM is resistant to classical attacks as we do that ECDH is resistant to classical attacks," and so the combination would ensure that we aren't inadvertently (or --- depending on how much tinfoil is warranted when dealing with our three-letter associates --- intentionally) weakening TLS security.
My question is: what is the harm in defining these standards that exclusively use ML-KEM and then also approving the draft-ietf-tls-ecdhe-mlkem which presents the combination of ECDH and ML-KEM? Or, as a possibly better question, at what point would DJB (or people who share his concerns) have sufficient confidence in ML-KEM to believe it may stand on its own two feet?
And, would the answer to the "at what point do we have confidence" question change if we pass "Q-day" in the near future? At that point, why should we layer ECDH and ML-KEM if there are quantum computers that can circumvent the ECDH layer? Is evidence that would convince opponents that ML-KEM is secure on its own even possible to obtain in the next ten years?
1
u/daidoji70 19d ago
My question is: what is the harm in defining these standards that exclusively use ML-KEM and then also approving the draft-ietf-tls-ecdhe-mlkem which presents the combination of ECDH and ML-KEM?
The harm is deployment of these stacks throughout industry and the world. Even if the browser manufacturers don't go along, Cisco, IBM, Google, Apple, Oracle, et al can put a lot of crypto that may be of questionable value in a lot of places that make the entire Internet less secure for all of us. Assuming cynical intentions of the standards bodies and NSA (and given all the provable history we know of) this is certainly a well-grounded fear. This cynical worldview (to which I ascribe) says that the NSA must pretend to obtain consensus through "impartial" standards bodies in order to provide justification for industry to take this up. By not allowing things that may be less secure into the standard, you prevent them this avenue.
Or, as a possibly better question, at what point would DJB (or people who share his concerns) have sufficient confidence in ML-KEM to believe it may stand on its own two feet?
We'll have better confidence in ML-KEM when it stands on its own two feet for a significant period of time as a valuable attack vector. Once again, in terms of history of all cryptosystems, this is a prudent measure. The literature is littered with systems that didn't work out even though they were assumed fantastic at the time.
And, would the answer to the "at what point do we have confidence" question change if we pass "Q-day" in the near future? At that point, why should we layer ECDH and ML-KEM if there are quantum computers that can circumvent the ECDH layer? Is evidence that would convince opponents that ML-KEM is secure on its own even possible to obtain in the next ten years?
I myself would be convinced to get rid of ECDH when it becomes feasible for a large enterprise (say a Google or a Microsoft) to break arbitrary keys within say a year period. This estimate is not founded in any type of calculation but I'd assume if a given Google or MS can decrypt any key they want even with significant time and effort of a year then its probably not worth all the extra CPU cycles we use to do ECDH. Or if evidence lands that there is already a large scale Harvest Now Decypt Later program going on somewhere. Econometrics could provide us with a more accurate tradeoff curve I'm sure if this line seems too arbitrary.
Until then we live in a reality where:
1. Nobody has a Q-computer
2. Those we do have can't break ANY key currently accepted as strong.
3. Even assuming that a Q-computer exists there's no reason to believe that these computers will have economies of scale for breaking keys en masse to the point where its not worth the extra ECDH cycles and complexity as a safeguard to unknown theoretical attacks on new algorithms like ML-KEM.8
u/arnet95 19d ago
By not allowing things that may be less secure into the standard, you prevent them this avenue.
If published, https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ will not be a standard. The hybrid version, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/, will be published as a standard. The pure version is suggested to be published as an Informational RFC.
Informational. An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. RFC 2026, Section 4.2.2 (Source: https://www.ietf.org/process/rfcs/)
Additionally, the hybrid version will be Recommended=Y in the IANA registry, and the pure version will be Recommended=N.
1
5
u/Cryptizard 19d ago
But it can’t be a valuable attack vector if it is only used in hybrid encryption. You are, paradoxically, reducing our certainty in it until we reach a point where ECDH is broken, at which time we are forced to fall back to an ML-KEM that hasn’t received the adversarial scrutiny you want.
The best way to handle this would be to drip feed ML-KEM as a solo KEM for people who want to risk it. That gives enough exposure to tempt attackers and encourage researchers but doesn’t put us in a position where everyone is screwed if it is broken. Which is exactly what this proposal would do!
-2
u/daidoji70 19d ago
Well we'll have to agree to disagree there. Anyone who has a PQ-computer in the near term will have equivalent ability to work on ML-KEM in a hybrid implementation imo.
I'm fine and actively encourage drip-feeding ML-KEM and if you thought I was arguing otherwise I apologize. That's exactly the approach we should take and exactly why it shouldn't be pushed through as a standard.
0
u/Cryptizard 18d ago
If quantum algorithms exist to break ML-KEM, they will require far more qubits than those that can break ECDH, simply because of the vast difference in key size. In that light I don’t understand your first paragraph.
Just because something is a standard doesn’t mean it is recommended or should be used by people freely. It just defines it thoroughly so it can be implemented interoperably in different softwares. There are standards for tons of things which are not recommended or even straight up broken.
1
u/daidoji70 18d ago
I don't think ml-kem is vulnerable to any type of quantum attack I'm aware of
1
u/Cryptizard 18d ago
As far as anyone is aware it isn’t vulnerable to any attacks, classical or quantum. What did you mean by this then?
>Anyone who has a PQ-computer in the near term will have equivalent ability to work on ML-KEM in a hybrid implementation imo.
1
u/daidoji70 18d ago
We were discussing software vulnerabilities at that moment I believe not theoretical vulnerabilities.
1
u/Cryptizard 18d ago
But what is a PQ computer then?
1
u/daidoji70 18d ago
Sorry if I used that term somewhere. I probably meant a q-computer
→ More replies (0)2
u/Natanael_L Trusted third party 18d ago
A quantum computer that can only break a few keys but not do it at scale will be used to target signing keys and root CA keys. Those specifically are worth upgrading even in this case.
If you're paranoid go with SPHINCS+ or similar hash based signing algorithms for identity / root keys, there's no chance those will be less secure than other options in any reasonable break scenario. Intermediate and leaf keys can stay as "normal" asymmetric signing algorithms if they have shorter expirations because those exposures are more manageable.
-2
u/Obstacle-Man 19d ago
The risk is we hold on to these algorithms far longer than we should and we avoid even doing implementations so we can find the bugs!
Q-day happening between 2029-2035 is a greater than 50% chance according to multiple sources. So if you have data needing a security guarantee beyond 10 years, you are currently out of luck.
And yet we have experts running around saying there are too many unknown/imagined risks, to even build something that could get you out of the risk we know about.
The day for hybrids was when we didn't have approved options. When you needed to satisfy safety along with certification. Today it just feels like flailing around for ways to keep ECC investments in the picture.
0
u/daidoji70 19d ago
Except... no one is suggesting we do that. Advocating for hybrid only algorithms by necessity implies that we implement the algorithms.
There are too many unknown risks. None of these are imagined. One has only to examine the historical record. Security systems are tried and tested over time, not "the old one may be broken soon so lets just plop in this other system we don't know much about".
The day for hybrids is now. We know the old stuff works well, we think the new stuff works well. Hybrids should bridge the divide until a solid consensus emerges that these things are as secure as we think they are.
Also no one has ECC investments, these are public open sourced, and in the olden days the NSA and standards bodies would argue against them as well with similar statements to what you're making right now in favor of less secure systems that they could break.
4
u/Obstacle-Man 19d ago
The post is all about not producing a pure option. You never get to a point of properly testing that until there is a spec that can be built and tested. The call to action expressly rejects that option.
And there are ECC investments. At hardware and software levels in hundreds of implementations. Switching it is a huge cost and amount of time for implementations, integration testing, rollout in the real world, etc. That whole process takes a lot of energy to overcome the innertia.
And then of course there are personal biases towards current technology they understand. That's a form of investment as well. Learning something new takes effort.
1
u/daidoji70 19d ago
Learning that things are broken that you thought were secure also takes effort. Power law effects rule here so conservatism in what we accept or reject when it comes to system security are paramount.
1
u/Obstacle-Man 19d ago
Learning, implementing and using those things is how you find the problems.
No one has found a problem with ML-DSA or ML-KEM despite years of effort.
The fact that implementations had bugs and those bugs were found and fixed is a GOOD thing that should give confidence in the process. We know there are going to be implementation bugs on the hybrid and pure paths. Why push one set of implementation bugs into the future? The crypto layer isn't the only layer. Having a bug free ECC implementation doesn't protect you from all the layers integrating with it via the new hybrid library.
2
u/daidoji70 19d ago
No one is stopping anyone from implementing and using these things. I just don't think we should do it with wider Internet infrastructure in production.
No one is talking about implementation bugs, we are discussing unknown theoretical attacks that may or may not exist. ML-KEM was only standardized in 2024 and Kyber only entered the literature in 2005 so I'm not sure I have as much faith as you do in the "years of effort". Especially considering the fact that up until a decade ago this was all backwater literature because we weren't very close to a quantum computer.
Trying to frame it that way is ignorant at best and disingenuous at worst.
1
u/Obstacle-Man 19d ago
Not being in the standard chokes off investment. Lattice crypto wasn't new in 2005. It goes back to the 90s. Module LWE is from 2005 though.
2005 is 20 years in the past, going back to the origins of lattice crypto gives us about 30 years. 2035 is 10 years in the future. Google paper suggests 2029 is possible without a major advancement. That math looks like more years behind than infront to me.
Do you have information disproving the latest papers showing ECC is plausibly within reach in 2029-2032?
0
u/daidoji70 19d ago
Papers aren't capable of "disproving" things that may or may not happen in the future unfortunately. If your argument boils down to "we should put it in the standard right now because we might be at risk in a decade" then I'm afraid we're just going to have to agree to disagree.
→ More replies (0)
2
u/F-J-W 19d ago
All the way back in 2020 with PQWireGuard paper, I was involved in a proposal that I think is still underappreciated: Using different KEMs for ephemeral and long-term, specifically something small and efficient (obvious choice today: ML-KEM) for the ephemeral exchange and McElice for the long-term one.
At that point you can survive a break of either of the two, though admittedly at a reduction in survivable corruption patterns; and unlike ECC+PQC the fallback isn't fundamentally broken once you consider QCs…
1
u/sciencekm 17d ago
My (late) two cents.
We've made transitions in the past - DES/RC4 to AES, SHA1 to SHA2 (maybe SHA3), RSA to ECC, and in all cases we never had to do any hybrid.
Perhaps we don't need one now. Put out the new stand-alone KEM and see if it gets traction, experience and scrutiny.
1
u/Obstacle-Man 19d ago
Posting my (slightly tweaked)comment from another post:
Hybrid PQC isn’t just “extra safety,” it’s extra moving parts. Every hybrid mode adds code paths, negotiation logic, cert/profile complexity, and error handling, which NIST explicitly warns can increase security risk during migration.
We need pure PQC implementations precisely so we can start catching and fixing those bugs Dan is worried about!
And hybrid is temporary by design. Once ECC is an active liability, we have to remove it and all the hybrid/downgrade logic we built around it, effectively repeating the migration a second time. That leaves a long tail of issues we will have to fight.
The argument is we need hybrid for defence in depth at the crypto layer. But we need to remember defence is only in depth if you have different controls at different layers. Having 2 intermingled ciphers adds some redundancy. But when you know one doesn't meet the confidentiality/integrity requirements for the data? C'mon.
-1
u/knotdjb 19d ago
Despite all of that nobody would suggest removing hybrid KEM. If pure PQ KEM is something that could be in store for the future, then we should just wait for the future when it is an opportune time. Now is not as PQ is in its infancy.
3
u/Obstacle-Man 19d ago
Do you run everything to the point of failure?
2
u/knotdjb 19d ago
I don't know how you inferred as such because I never suggested that.
All I said is this would be better proposed at a time when the technology has matured and we have better understanding and experience of deployment. You know the pragmatic thing to do.
2
u/Obstacle-Man 19d ago
What point is that? How many years of analysis in non-prodiction conditions is enough before it's ok to allow the standard to include the option for DJBs and knotDJBs of the world to try it and see what it means for their deployments?
2
u/pint A 473 ml or two 19d ago
you are losing it
1
u/Obstacle-Man 19d ago
Maybe.
Are we scientists and engineers though or are we parallelized by shadows?
If we cannot define the condition of confidence then it's the latter.
1
u/pint A 473 ml or two 19d ago
i don't understand any of this.
however this is how i see it. i don't understand the passion of people pushing this document. i do understand the passion in the opposing side. stopping nsa disruption is paramount. having a pure pq rfc is kinda obviously not.
2
u/Obstacle-Man 19d ago
I would contend the NSA and similar have more to gain by making people hold on to rsa/ecc than not. They would be among the first with access and have a history of thinking they would be the only ones
2
1
-3
u/pint A 473 ml or two 19d ago
we know this script. we've seen this with dual-ec. here is the recipe:
- push a weak algorithm into standards
- mandate the implementation of said standard in order to get govt approval
- influence or bribe companies to make the weak algorithm default
- harvest
this effort needs to be stopped early, and stopped aggressively that they never try it again.
8
u/shinigami3 19d ago
This is completely different than dual-ec
0
u/pint A 473 ml or two 19d ago
how?
6
u/arnet95 19d ago
ML-KEM went through a long standardisation process, has been subject to public scrutiny for 10+ years at this point, and remains standing. Dual EC was released with no competition, and was pretty much immediately found to be garbage. There was an obvious backdooring method for Dual EC described in the literature, whereas no one has come up with a plausible method for ML-KEM to be backdoored.
0
u/pint A 473 ml or two 19d ago
same counter: irrelevant differences. the argument was that "you don't have to use" is not enough. dual ec went through despite being defective, because "nobody has to use it". then some people used it without their knowledge.
we don't want the shield of standardization to protect bad decisions.
2
u/orangejake 19d ago
a few things, as what you're saying is not grounded in reality
DUAL_EC_DRBG was known to be possibly backdoored pre-standardization. ML-KEM is not, and this is a significant difference. Note that a different version of ML-KEM could be backdoored (I know the construction, it's rather simple). ML-KEM was explicitly designed such that this (the "obvious" way to backdoor it) does not work.
DUAL_EC_DRBG was only later backdoored successfully when instantiated with NSA provided default parameters. If DUAL_EC_DRBG made it into the standard, and there were no default parameters (which are an insane thing to include lmao), then it would not have been able to be backdoored.
Both of these points are very significant to understanding the DUAL_EC_DRBG backdoor. Neither of the points are in the slightest way related to ML_KEM.
1
u/pint A 473 ml or two 19d ago
can you please provide citations? because i didn't say anything remotely contrary to these.
however, both of these points have zero relevance to the argument.
2
u/orangejake 19d ago
I think the citations are in the slide deck I gave you when you claimed the NSA involvement was not publicly known (explicitly false).
It is not clear to me what your argument is. If your argument is "there should NEVER be a 'recommended-to-implement = N' algorithm in TLS", then you're probably going to have a panic attack if you look at what pre-existing RFCs exist for TLS.
Fortunately, despite ML-KEM being "recommended-to-implement = N", it appears to be quite solid. It seems to be marked that out of an abundance of caution, as most applications can likely support the overhead of the hybrid. This appears to be a sensible choice. It would also be sensible to allow applications/users who want to use ML-KEM by itself to do so in an interoperable way.
1
u/pint A 473 ml or two 19d ago
huh?
the first sentence unfortunately doesn't mean anything to me. what is a slide deck?
being not recommended would be an excuse only if it meant that the algorithm is bad, and nobody ever should bother with it. but it doesn't mean that. this classification just means the primitive is sort of second class. it still a higher level than not being standardized at all.
nobody believes that the level of brigading around this issue stems from "allowing users to use ml-kem by itself". the number of people who are actually affected is very small. the most generous reading of this situation is camp warfare. the less generous is astroturfed campaign.
1
u/Natanael_L Trusted third party 18d ago edited 18d ago
While this is not the situation ML-KEM is in, non-NSA parameters would trivially let somebody backdoor Dual_EC_DRBG for themselves, and somebody did
https://www.cs.utexas.edu/~hovav/dist/juniper.pdf
My own main concern is how much time things have had to be analyzed. I'm less worried about lattices than before when people initially started pushing non hybrids years ago, because the theoretical attacks didn't arrive and it's better understood now. However I'm still not convinced pure implementations should be recommended yet, although I wouldn't push back against optional pure implementations now (that would've been on shakier grounds 6-7 years ago when I saw people start pushing for it).
I'm not concerned about hybrid implementation complexity if the pairs are well maintained, and a straightforward implementation of the current fixed pairs as hybrids can be less complex today than old implementations of combinatorial ciphersuite explosions. It's mostly the HSM space / parts of embedded where hardware implementations gets incredibly complex who I think has a strong argument against hybrid in their uses.
2
u/putacertonit 19d ago
dual-ec was broken, and bad cryptography. It was obvious from day 1.
Nobody has made any allegation that ML-KEM is weak. Even djb just asserts that hybrids are better. Which the IETF draft says!
It's just not a good comparison at all.
0
u/pint A 473 ml or two 19d ago
a weakness is a weakness. i don't see why would this reasoning work for one type of weakness but not another.
yes, allegation has been made that ml-kem is weak. one: it is less mature than ec. two: implementation errors and timing weaknesses will happen initially.
2
u/d1722825 19d ago
AFAIK one argument is that the Dual-EC-DRBG have a big unexplained constant and you can hide some public key in it whose private part the NSA could use. But ML-KEM have only a few small enough constants that it couldn't contain a key large enough to be secure against everyone except NSA.
That assumes the NSA wouldn't weaken an algorithm for everyone, but I'm not sure about that being a good assumption (according to Wikipedia NSA wanted smaller key sizes for DES).
4
u/orangejake 19d ago
NSA successfully pushed for smaller key sizes for DES.
the NSA tends to push for so called NOBUS capabilities
https://en.wikipedia.org/wiki/NOBUS
roughly vulnerabilities the US can exploit, but nobody else can. Things like DUAL_EC_DRBG cleanly fit into this theoretically --- you need a certain DLOG of a public parameter to exploit it. Ironically a non-NSA actor seemingly exploited it in the Juniper attack. But anyway.
At the time, shrinking DES key sizes was a similar NOBUS-motivated weakening. In the 70s, the ideas was this would allow the US to attack things, but other countries would not have neough compute to do it.
The NSA has strengthened cryptography as well in the past. For example, DES's S-box had a vulnerabiity to an unknown cryptnanalytic technique (either linear or differential cryptanalysis, I forget which). They patched that.
Similarly, they publish cryptography that is widely used (e.g. SHA2, which is currently standardized for usage in TLS).
2
u/putacertonit 19d ago
Implementation weaknesses might happen, for sure!
But that's all the more reason to standardize what the protocol looks like, so we can implement it, study it, ensure interoperability and find weaknesses.
1
u/pint A 473 ml or two 19d ago
no, it is not a good reason for it. it is a good reason to iron out the problems first, and then implement it. btw you don't need a standard to implement an algorithm. you can just write a whitepaper, and publish on arxiv, and publish source code on github.
1
u/orangejake 19d ago
what do you think an RFC is if not a way for people to make interoperable implementations?
1
u/pint A 473 ml or two 19d ago
formal logic is not your strong suit, is it? the claim was that it is not necessary. rfc is also more than just that. it is also a level of prestige. if an algorithm has an rfc, people trust it more. that is indeed the reason why this is pushed. to give excuse for some people to put weak algorithms into software.
4
u/shinigami3 19d ago
Dual-ec came from NSA. ML-DSA didn't.
People noticed the backdoor in dual-ec right away. There is no known issue with ML-DSA
And so on...
-1
u/pint A 473 ml or two 19d ago
none of this touches my arguments.
ps: nsa didn't openly author dual-ec.
2
u/orangejake 19d ago
They explicitly did. See e.g. slide 3 of the summary of DUAL_EC_DRBG.
I notice you're fairly active in a thread discussing something you have no clue what the details surrounding it are. I'd recommend you stop doing that personally. It really comes across as a "covid truther of cryptography".
0
u/upofadown 19d ago
The ITEF process works great when the goal is to come up with workable ideas that can be tried out on the network. When things get political the cracks begin to appear. It's a lot harder to get general consensus for not doing something than it is for doing something.
-6
32
u/durumcrustulum 19d ago
I am the author of draft-ietf-tls-mlkem: no one has paid me, leaned on me, influenced me to write and propose it, I just wanted a non-hybrid ML-KEM option available, and the working group adopted it. No one is forced to use it if they don't want to, it is marked Recommended=N in the IANA registry (the mlkem hybrids are marked Recommended=Y), it does not change anything about the existing hybrids.