NSA and IETF: Fairness • Hacker News Board

Re: NSA and IETF: Fairness

#21

Post by ekr____ » Tue, Jul 07, 2026, 2:24 AM UTC

eqvinox wrote: post #18

ekr____ wrote: post #11

Earlier quoted context omitted.

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 t…

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…

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.

Re: NSA and IETF: Fairness

#22

Post by LastTrain » Tue, Jul 07, 2026, 2:25 AM UTC

ButlerianJihad wrote: post #17

eqvinox wrote: post #4

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…

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 p…

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

Re: NSA and IETF: Fairness

#23

Post by eqvinox » Tue, Jul 07, 2026, 2:28 AM UTC

ButlerianJihad wrote: post #17

eqvinox wrote: post #4

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…

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 p…

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

Re: NSA and IETF: Fairness

#24

Post by teravor » Tue, Jul 07, 2026, 2:29 AM UTC

tptacek wrote: post #8

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 cla…

    > Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.

this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.

Re: NSA and IETF: Fairness

#25

Post by eqvinox » Tue, Jul 07, 2026, 2:31 AM UTC

ekr____ wrote: post #21

eqvinox wrote: post #18

Earlier quoted context omitted.

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…

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 ch…

Thanks for the link to that amazing document!

Re: NSA and IETF: Fairness

#26

Post by maqp » Tue, Jul 07, 2026, 2:44 AM UTC

iririririr wrote: post #20

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.

Re: NSA and IETF: Fairness

#27

Post by dhx » Tue, Jul 07, 2026, 2:49 AM UTC

teravor wrote: post #24

tptacek wrote: post #8

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 cla…

> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC. 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

Re: NSA and IETF: Fairness

#28

Post by chrismorgan » Tue, Jul 07, 2026, 2:50 AM UTC

throw0101d wrote: post #15

ekr____ wrote: post #10

Earlier quoted context omitted.

> (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…

> 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 s…

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

Re: NSA and IETF: Fairness

#29

Post by tptacek » Tue, Jul 07, 2026, 2:51 AM UTC

teravor wrote: post #24

tptacek wrote: post #8

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 cla…

> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC. this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.

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.

Re: NSA and IETF: Fairness

#30

Post by tptacek » Tue, Jul 07, 2026, 2:52 AM UTC

dhx wrote: post #27

teravor wrote: post #24

Earlier quoted context omitted.

> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC. 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 the…

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.