"The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism."
The french position, also quoting the German position:
"As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybrid wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"
The two most important things to understand about this kerfuffle:
(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.
> (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.
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.
> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.
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:
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).
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document
“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.
These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.
It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.
I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)
As I thought you were aware [1], RFCs are treated as a green light by industries. In the last call itself, the Canadian Cyber Centre said they would use this RFC in particular to justify recommending solo ML-KEM across their nation, proving this point.
I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered.
I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DARPA, after all) but Internet protocols were so ridiculously insecure, and based on absurd trust models that were repeatedly broken, and everything always transmitted in plaintext (because, of course, all networks were physically wired, secured, and only the good guys could tap into them).
It was an absolute Wild West clown college as the Internet transitioned to commercial and privatized use cases, and I suppose it guaranteed job security for generations of cybersecurity experts and cryptographers.
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.
He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.
I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.
That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.
Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.
Even the side channel stuff in particular --- Bernstein was certainly a popularizer of it, but that's been mainstream in cryptography research since the mid-2000s (and, obviously, it's Paul Kocher's claim to immortality).
One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.
Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.
This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"
ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:
From draft-ietf-tls-mlkem-8:[1]
"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."
From NIST SP 800-227:[2]
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."
MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
As a point of reference for how hard it is to implement side channel resistant MLKEM see [4]. The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.
I, for one, wouldn't care if Kanye West or his aunt or her neigbours dog came up with a good encryption algo. If it's good, it's good no matter who wrote it. Appeals to authority or the lack thereof draws attention away from the technical debate.
Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.
For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.
For example:
FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]
NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]
RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]
A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].
A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.
No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.
the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more.
having said that, I would trust McEliece more than Kyber.
You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.
He didnt say it did, he said "The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber"
Yes, and strongly argued against lattice schemes generally. DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one.
DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (which are excellent except for the ginormous public keys), and spent many bytes trying to convince people that the set of applications that can is wider than they suspect.
I certainly find it fascinating that the majority of those in favor come from signal intelligence agencies, while the majority of those against are PhD cryptographers.
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice...
The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel its use.
On one hand MLKEM by itself seems like a better choice than DUAL-EC, on the other hand that fact should make it much easier for a powerful attacker to cause a target to use it if you do have an attack that exploits this fact.
MLKEM was selected out of myriad other options through a NIST process which was directly influenced by NSA (including in manners that NIST failed to disclose and actively mislead the group about). I think this makes the commentary regarding NSA highly relevant. While it seems less like that NSA already knows of a total break in MLKEM (and indeed their influence could have been in a strengthening direction...) it's possible that their influence was motivated by things like that ease of undetectably compromising specific implementations through techniques like dopant adulteration or specialized side channel weaknesses.
If your plan it to tamper with chip mfgr or hit them with a very well aimed e-beam (e.g. to cause ion migration) after the fact then having a non-hybrid scheme is pretty obviously going to make your life much easier... Or perhaps they've taken a route similar to the one they took with Crypto AG-- this time positioning themselves as a fabless silicon vendor to sell MLKEM RTL to a market that doesn't have an implementation but already has many robust ECC implementations to choose from.
...and that's without getting into the unknown possibility of a cryptoanalytic breakthrough.
I don't think it's even safe to say that NSA would only consider NOBUS backdoors-- I don't think any of us can know how inadvisably arrogant the relevant decision makers may be and what they might consider NOBUS. Given how DUAL_EC went in Netscreen's products I think it's reasonable to argument that there is no such thing as a NOBUS backdoor when push comes to shove. Capping DES's key size is candidate example of a very much non-NOBUS weakness that NSA felt comfortable with, as one needed a particularly amount of strength to exploit it which they believed that only they had. Today, of course, a child's video game device can crack DES as a direct product of that part of their influence.
Not a great track record when fear of "store and decrypt later" attacks is much of what motivates the use of PQ key agreement today.
The consistent aggression five-eyes affiliated cryptographic-intelligence groups have had for hybrid schemes is truly difficult to comprehend-- given that practically everyone else considers them obviously prudent in all cases where the resource costs permit -- and I think this justifies the utmost concern and caution. And in terms of caution hybrid schemes are table stakes.
A major theme of DJB's cryptographic security advocacy is that cryptographic security is often as much about what you don't offer as it is what you do. A completently engineered security product is misuse resistant and it's not completely clear to me that a standard which offers the choice of a non-hybrid mlkem qualifies as misuse resistant.
That said, there are plenty of drafts that are in no way misuse resistant. :)
DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against?
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?
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".
> 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.
Thanks for the clarification. It’s a bit of a shame as going via ISE would have let the group move onto other endeavours. Maybe people will just refer to the draft name and that’s that.
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...
> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES
Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?
MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe
As you know, teams are vulnerable to infiltration and individuals to compromise. Corruption often stems from various motives, including ideology
DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers" (ed.: I am one).
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:
[…] must be documented in a permanent and readily
available public specification, in sufficient detail so that
interoperability between independent implementations is possible.
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:
4588 X25519MLKEM768 Combining X25519 ECDH with ML-KEM-768 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem-05
[ed.2: this is getting a funky spread of up & down votes, any of the downvoters mind commenting why they're downvoting?]
Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft.
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.
Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.
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.
Sadly, a similar myth/fallacy persists about the Wikipedia consensus process (at least the English project and others deriving policy from it.)
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.)
There is a small and noisy contingent here that never fails to get bent about community driven projects accusing them of bias and insinuating that there is some kind of shadowy cabal running things and it would be hilarious if the reasons for it weren’t so transparent. Also those people are 100 percent MAGA
From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html)
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.
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.)
He famously doesn't support the IETF. In the long-long-long ago, back when I had a "home page" with my username and a tilde in it, I used to have a quote from him on it about the IETF and "ego standards". He's been picking fights like this with different IETF working groups for basically his entire career. This isn't even the first time he's picked a huge fight with IETF cryptography groups; he managed to get Kenny Paterson to publicly take him to task on the CFRG a few years back.
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.
> whether he realizes it or not, he's operating in supremely bad faith this time.
I've met him in person, once, at a CCC event about a decade ago, and as someone clueless about cryptography all I can say to that is that he certainly had (has?) a my-way-or-the-highway personality.
> I, too, don't support the IETF
Out of curiosity, how would you maintain e.g. TLS? Something more academic? Raw "throw it all out there, best-wins"? Another SDO (e.g. ITU)? Other more formal international processes?
For the record, he's always been extremely nice to me, online and in person, and generous with his time.
I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
> I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)
But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)
WireGuard in particular is both an implementation and a design, and the design effectively belongs to Jason Donenfeld.
The problem with cryptographic standards bodies is that committee-based design has a long track record of weakening protocols. Originally, part of the ethos of the IETF was that it was merely providing interop for things that were already happening; rough consensus around real implementations. But that attitude expired decades ago; things are now designed de novo in working groups.
Through a herculean effort, TLS-WG managed through that fucked process to drastically improve TLS in 1.3. It did that in part because a team of cryptographers and cryptography engineers camped on the working group and made sure the outcome was sane. And they nearly failed! Banks fought hard to try to keep static handshakes in the new version, so they could do compliance intercepts.
Unfortunately, fully documenting PQC cryptography isn't as glamorous a task as defining the next generation's version of TLS. And yet, we've got a somewhat diverse team of cryptographers on the working group lined up against Bernstein on this.
The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.
if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.
Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
> is going around the encryption by hacking endpoints
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)?
This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is much more mysterious and spooky than they think it is.
(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.)
> The more cryptography-literate you are, the more likely it is you think hybrids are silly
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.
To those who say that approving or not this RFC won't make any difference:
«- Liaisons: We received liaison statements from multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference»
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.)"
Disappointed that there is not more discussion about this as this looks to be a slow march to the government getting its way with a technology that will affect so many.
France and Germany propose hybrid schemes as well: The german position:
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...
"The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism."
The french position, also quoting the German position:
https://cyber.gouv.fr/sites/default/files/document/follow_up...
"As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybrid wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"
The two most important things to understand about this kerfuffle:
(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.
> (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.
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.
The ISE has said they aren't progressing crypto drafts anymore.
> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.
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".)
You're right. Bad writing on my part. Edited to make it clear.
> https://www.iana.org/assignments/tls-parameters/tls-paramete...
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...
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document
“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.
These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.
If it's documented it will be implemented by many more libraries and applications, that's the argument
It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.
Can you (or someone else) please give some example of those environments?
Telecoms.
I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...
I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)
As I thought you were aware [1], RFCs are treated as a green light by industries. In the last call itself, the Canadian Cyber Centre said they would use this RFC in particular to justify recommending solo ML-KEM across their nation, proving this point.
[1] Sadly, I know you are aware.
If it's supported it will be used, e.g. by vendors which decide for some reason to use it
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.
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
They publish what become standards, you can't just support any existing option in an encryption protocol (if you want to have a secure one).
Heh heh heh.
I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered.
I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DARPA, after all) but Internet protocols were so ridiculously insecure, and based on absurd trust models that were repeatedly broken, and everything always transmitted in plaintext (because, of course, all networks were physically wired, secured, and only the good guys could tap into them).
It was an absolute Wild West clown college as the Internet transitioned to commercial and privatized use cases, and I suppose it guaranteed job security for generations of cybersecurity experts and cryptographers.
The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.
this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.
To extend on this good point--
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
He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.
I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.
That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.
The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.
Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.
Even the side channel stuff in particular --- Bernstein was certainly a popularizer of it, but that's been mainstream in cryptography research since the mid-2000s (and, obviously, it's Paul Kocher's claim to immortality).
One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.
"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023"
Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.
Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.
We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.
So clearly when I go look back at the archives of Bernstein discussing 25519, I'm going to see him advocating for FFDH/25519 cascades, right?
(If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)
Was FFDH considered safe?
> the implementation history of ECC is godawful
You do know that new cryptographic code can be godawful, then?
This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"
ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:
From draft-ietf-tls-mlkem-8:[1]
"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."
From NIST SP 800-227:[2]
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."
MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
As a point of reference for how hard it is to implement side channel resistant MLKEM see [4]. The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1
[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...
I, for one, wouldn't care if Kanye West or his aunt or her neigbours dog came up with a good encryption algo. If it's good, it's good no matter who wrote it. Appeals to authority or the lack thereof draws attention away from the technical debate.
Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.
For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.
For example:
FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]
NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]
RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]
A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].
A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.
[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1
[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...
No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.
the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more.
having said that, I would trust McEliece more than Kyber.
You would trust McEliece more than Kyber because...
[delayed]
> nothing that's happening here has really anything to do with NSA
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...
You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.
The NSA had nothing to do with designing Kyber.
He didnt say it did, he said "The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber"
He himself (co-)submitted a lattice KEM to the NIST competition.
Yes, and strongly argued against lattice schemes generally. DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one.
DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (which are excellent except for the ginormous public keys), and spent many bytes trying to convince people that the set of applications that can is wider than they suspect.
I certainly find it fascinating that the majority of those in favor come from signal intelligence agencies, while the majority of those against are PhD cryptographers.
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice...
The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel its use.
On one hand MLKEM by itself seems like a better choice than DUAL-EC, on the other hand that fact should make it much easier for a powerful attacker to cause a target to use it if you do have an attack that exploits this fact.
MLKEM was selected out of myriad other options through a NIST process which was directly influenced by NSA (including in manners that NIST failed to disclose and actively mislead the group about). I think this makes the commentary regarding NSA highly relevant. While it seems less like that NSA already knows of a total break in MLKEM (and indeed their influence could have been in a strengthening direction...) it's possible that their influence was motivated by things like that ease of undetectably compromising specific implementations through techniques like dopant adulteration or specialized side channel weaknesses.
If your plan it to tamper with chip mfgr or hit them with a very well aimed e-beam (e.g. to cause ion migration) after the fact then having a non-hybrid scheme is pretty obviously going to make your life much easier... Or perhaps they've taken a route similar to the one they took with Crypto AG-- this time positioning themselves as a fabless silicon vendor to sell MLKEM RTL to a market that doesn't have an implementation but already has many robust ECC implementations to choose from.
...and that's without getting into the unknown possibility of a cryptoanalytic breakthrough.
I don't think it's even safe to say that NSA would only consider NOBUS backdoors-- I don't think any of us can know how inadvisably arrogant the relevant decision makers may be and what they might consider NOBUS. Given how DUAL_EC went in Netscreen's products I think it's reasonable to argument that there is no such thing as a NOBUS backdoor when push comes to shove. Capping DES's key size is candidate example of a very much non-NOBUS weakness that NSA felt comfortable with, as one needed a particularly amount of strength to exploit it which they believed that only they had. Today, of course, a child's video game device can crack DES as a direct product of that part of their influence.
Not a great track record when fear of "store and decrypt later" attacks is much of what motivates the use of PQ key agreement today.
The consistent aggression five-eyes affiliated cryptographic-intelligence groups have had for hybrid schemes is truly difficult to comprehend-- given that practically everyone else considers them obviously prudent in all cases where the resource costs permit -- and I think this justifies the utmost concern and caution. And in terms of caution hybrid schemes are table stakes.
A major theme of DJB's cryptographic security advocacy is that cryptographic security is often as much about what you don't offer as it is what you do. A completently engineered security product is misuse resistant and it's not completely clear to me that a standard which offers the choice of a non-hybrid mlkem qualifies as misuse resistant.
That said, there are plenty of drafts that are in no way misuse resistant. :)
DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against?
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?
> …information RFC? He can’t stop that, right?
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".
This document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).
> 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.
Thanks for the clarification. It’s a bit of a shame as going via ISE would have let the group move onto other endeavours. Maybe people will just refer to the draft name and that’s that.
This post was pretty technical. Let's explain a couple of terms:
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 they know something we don't
Perhaps
https://blog.cr.yp.to/20260704-bugs.html#damage
> In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc
Actually, Dr. Nadim Kobeissi formally proved that hybrid is secure, even if ML-KEM fails. [1]
[1] https://eprint.iacr.org/2026/1147
> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES
Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?
It's complicated. The federal government pushed for a smaller DES key size, but also fixed the DES s-boxes to resist differential cryptanalysis.
Sure. Everbody knows that
As you know, teams are vulnerable to infiltration and individuals to compromise. Corruption often stems from various motives, including ideology
Is there anything different about this DJB mailing list brigading than the other brigading he's done?
Four days ago: https://news.ycombinator.com/item?id=48760490
By dint of not including a list of non-cryptographer cosigners, this one is prima facie somewhat less cringe.
DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers" (ed.: I am one).
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?]
Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft.
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.
> […] "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published […]
Yes, sorry, I was just covering against people nitpicking on the document status :)
Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.
Good question.
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.
Thanks for the link to that amazing document!
Sadly, a similar myth/fallacy persists about the Wikipedia consensus process (at least the English project and others deriving policy from it.)
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.)
There is a small and noisy contingent here that never fails to get bent about community driven projects accusing them of bias and insinuating that there is some kind of shadowy cabal running things and it would be hilarious if the reasons for it weren’t so transparent. Also those people are 100 percent MAGA
From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html)
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.)
He famously doesn't support the IETF. In the long-long-long ago, back when I had a "home page" with my username and a tilde in it, I used to have a quote from him on it about the IETF and "ego standards". He's been picking fights like this with different IETF working groups for basically his entire career. This isn't even the first time he's picked a huge fight with IETF cryptography groups; he managed to get Kenny Paterson to publicly take him to task on the CFRG a few years back.
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.
> whether he realizes it or not, he's operating in supremely bad faith this time.
I've met him in person, once, at a CCC event about a decade ago, and as someone clueless about cryptography all I can say to that is that he certainly had (has?) a my-way-or-the-highway personality.
> I, too, don't support the IETF
Out of curiosity, how would you maintain e.g. TLS? Something more academic? Raw "throw it all out there, best-wins"? Another SDO (e.g. ITU)? Other more formal international processes?
For the record, he's always been extremely nice to me, online and in person, and generous with his time.
I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
> I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)
But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)
WireGuard in particular is both an implementation and a design, and the design effectively belongs to Jason Donenfeld.
The problem with cryptographic standards bodies is that committee-based design has a long track record of weakening protocols. Originally, part of the ethos of the IETF was that it was merely providing interop for things that were already happening; rough consensus around real implementations. But that attitude expired decades ago; things are now designed de novo in working groups.
Through a herculean effort, TLS-WG managed through that fucked process to drastically improve TLS in 1.3. It did that in part because a team of cryptographers and cryptography engineers camped on the working group and made sure the outcome was sane. And they nearly failed! Banks fought hard to try to keep static handshakes in the new version, so they could do compliance intercepts.
Unfortunately, fully documenting PQC cryptography isn't as glamorous a task as defining the next generation's version of TLS. And yet, we've got a somewhat diverse team of cryptographers on the working group lined up against Bernstein on this.
He makes the legal argument in more detail in https://blog.cr.yp.to/20251004-weakened.html#standards
The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.
if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.
Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
> is going around the encryption by hacking endpoints
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)?
This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is much more mysterious and spooky than they think it is.
(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.)
> The more cryptography-literate you are, the more likely it is you think hybrids are silly
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.
It's "cipher". But we're not talking about ciphers; we're talking about key establishment algorithms.
Ok, yes, replace "cypher" with cryptographic primitive.
Maybe I said cypher for the AES+Serpent mention (and because I like cyberpunk xD)
It's cypher in British English.
To those who say that approving or not this RFC won't make any difference:
«- Liaisons: We received liaison statements from multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference»
(https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_...)
Highly recommended reading for effectively understanding the behavior patterns of bad-faith participants in such exchanges: https://www.scribd.com/document/345154863/Guide-to-Forum-Spi...
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.)"
From the other direction, the ITU-T has a highly regarded presentation on how to actually work with consensus procedures & establish said consensus:
https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Rein...
Disappointed that there is not more discussion about this as this looks to be a slow march to the government getting its way with a technology that will affect so many.