ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
48% Positive
Analyzed from 2784 words in the discussion.
Trending Topics
#ietf#tls#https#rfc#cryptography#mlkem#consensus#document#more#already
Discussion (65 Comments)Read Original on HackerNews
(1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to clarify the selection.)
(2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.
Every time Bernstein talks about NSA's sordid history, remember: nothing that's happening here has really anything to do with NSA. It would make more sense for Bernstein to be canvassing against SHA2, which NSA actually did design. But he can't do that, because normal people know enough about cryptography to understand how crazy a claim that is. Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.
Two more pieces of context here: 1. The IETF allows code point registrations based purely on the existence of a specification, and the pure ML-KEM code points have already been assigned (https://www.iana.org/assignments/tls-parameters/tls-paramete...). The question at hand is whether the IETF will publish an RFC documenting the ML-KEM cipher suites [edited to make clear that ML-KEM is documented already].
2. It is also possible to publish an RFC via what's called "Independent Submission" (https://www.rfc-editor.org/authors/rfc-independent-submissio...), which is not subject to the IETF Consensus process. This is, for instance, how the GOST RFC (https://datatracker.ietf.org/doc/rfc9367/) was published. If the IETF opts not to publish this draft, the authors can still submit it to the Independent Submissions Editor.
Further the draft that this is all about does not make a recommendation for its use. The currently IETF-recommended TLS algorithms are: X25519MLKEM768, x448, x25519, secp384r1, secp256r1.
As noted by someone on the IETF list [1] there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document. No one is forcing anyone to use this algorithm, and it's not even 'officially' recommended (per above).
[1] https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...
“People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.
(There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.)
This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.
Null encryption used to be supported as well, and no one was forced to use it.
But when something insecure is supported by a protocol it will lead to security hiccups.
If it's dangerous it shouldn't be supported.
The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short:
https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html
(This doesn't mean the document is a stub or pointless or something like that, you do need a "what goes where".)
having said that, I would trust McEliece more than Kyber.
DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.
For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?
See [1] and [2] for answers. Summary: Technology is not ready.
[1] https://dl.acm.org/doi/10.1145/3569420
[2] https://dl.acm.org/doi/10.1145/3779208.3785290
How can you say that???
It seems to be literally only for their claim to need it that pure MLKEM is being requested..!
A summary at https://blog.cr.yp.to/20251004-weakened.html, or just see e.g. https://keymaterial.net/2025/11/27/ml-kem-mythbusting for an opposite voice stating the same...
He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies).
What’s his next step if the authors publish as an information RFC? He can’t stop that, right?
This is a slightly complicated question. There are several main routes to an Informational RFC.
* Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages.
* Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed.
In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.
Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".
Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?
ML-KEM -- Module-Lattice-Based Key-Encapsulation Mechanism
ML-DSA -- Module-Lattice-Based Digital Signature Algorithm
solo PQ -- Using post-quantum crypto on its own
ECC+PQ -- Using post-quantum crypto as a layer on top of traditional elliptical curve cryptography (ECC)
So what's at stake here, is that the PQ crypto is not proven yet, and had recent implementation vulnerabilities (Kyberslash 1 & 2).
In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc. Perhaps they know something we don't. They have sometimes acted to strengthen public cryptography, as with the DES S-boxes and differential cryptanalysis. Of course, they also weakened the key-space...
Perhaps
https://blog.cr.yp.to/20260704-bugs.html#damage
Four days ago: https://news.ycombinator.com/item?id=48760490
Apart from that, the crux of this is the codepoint allocation in the named group registry. [https://www.iana.org/assignments/tls-parameters/tls-paramete...] The requirement for that allocation (with "recommended=N" - which is what this draft has) is "Specification Required", not "IETF consensus". "Specification" for IANA registries doesn't mean IETF documents, it means:
[https://datatracker.ietf.org/doc/html/rfc8126#section-4.6]As such I don't understand why the authors are so intent at ramming this through the IETF process when they could just put the same document whereever. The process has been sufficiently and publicly fraught enough to destroy any "reputation" that might (or might not) come associated with it being published as IETF RFC.
[ed.: referenced wrong registry, it's named groups, not cipher suites. Makes no difference, same registration procedure.]
FTR, the only [preliminary] entry with recommended=Y for PQ crypto is:
[ed.2: this is getting a funky spread of up & down votes, any of the downvoters mind commenting why they're downvoting?]The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/), it will replace the reference in the registry. However, it will have the same code point and the same semantics. If, for some reason, the IETF were to change the semantics, a new code point would have to be assigned for interop reasons.
If the document is dropped by the IETF, nothing at all would happen. It's already a valid code point registration, and indeed the authors could have just published the document, registered the code points, and stopped (see: https://datatracker.ietf.org/doc/draft-barnes-tls-this-could...).
If the authors decided to later pick up the document somewhere else, then they could probably get the reference changed to whatever that was, as long as the semantics were identical.
Yes, sorry, I was just covering against people nitpicking on the document status :)
Participants in disputes and RFCs literally call their comments “!vote” in true hacker notation, to repeatedly and clearly emphasize that “vote count” is never a factor in the process of establishing consensus.
(Elections are, however, regularly held, and votes counted, for positions such as Administrator, and the ArbCom seats, but that’s for people, not article content.)
Which is why I'm noting the alienation of "IETF believers", which I should maybe clarify I count myself as. The IETF is a lot of people doing a lot of good work. It does include a bunch of questionable actors, anything from ignorant, incompetent, ulterior motives, to outright malicious. But all in all it has brought us the internet as it exists today and I can't help feeling a little, well, alienated by DJB's writs.
[ed.:] https://blog.cr.yp.to/20251004-weakened.html#agreement says:
Anyway, IETF hasn't attempted to issue such a rule. On the contrary, IETF claims that WG decisions are not taken by voting: "Decisions within WGs, as with the broader IETF, are taken by 'rough consensus' and not by voting." This begs the question of what IETF thinks "rough consensus" means. Letting chairs make arbitrary decisions is a violation of due process.
More to the point, IETF can't override the definition of "consensus" in the law. That definition requires general agreement. Adoption of this draft was controversial, and didn't reach general agreement.
DJB making legal-ish arguments (or the idea that the IETF could be sued over a definition of "rough consensus") is absolutely inane to me. The choice of words of the IETF in defining its own processes for itself is not a legal one. And apart from that, which country's laws would that be? (I'm also quite skeptical about such a definition existing in a relevant manner to begin with.)
I, too, don't support the IETF (hence the quote on the web page, which I can't find now). But I happen to know enough about the people involved in this particular drama that I can see through his arguments here, and whether he realizes it or not, he's operating in supremely bad faith this time.
Because they weren't (supposedly) able to break the encryption
> than to attack the algorithms
You have an opportunity to introduce new, broken, algorithms; they exploited it with DES, tried to exploit it with ECC, why wouldn't they try it with post-quantum (which they've kind of been pushing)?
(I'm only somewhat cryptography-literate and so I would myself default to a hybrid, though that opinion might change the first time I bother banging together an MLKEM implementation.)
You are if you're considering a cypher that's extremely likely to be secure.
In this case we're ok to introduce something with a chance to be quantum-resistant before it's been studied enough, because we want a chance of being quantum-resistant soon.
But that's only ok if you add it to the existing, reliable, systems.
Were there not the issue of quantum computers we wouldn't even be considering to use different cyphers at this time.
If the link goes down, the content is available in many other places across the web under the title "The Gentleman's Guide To Forum Spies (spooks, feds, etc.)"
https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Rein...