Comment by eqvinox | Hacker News Reader

Comment by eqvinox | Hacker News Reader

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.

[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:

  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.

> […] "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!

The issue with saying that "there's a 60/40 split, therefore there's no consensus" is that the IETF explicitly documents that that isn't the case: RFC 7282, Section 7, "Five people for and one hundred people against might still be rough consensus" (https://datatracker.ietf.org/doc/html/rfc7282#section-7).

The working group chairs have to decide if all of the objections have been "addressed". However, "addressed" doesn't mean "fixed via changes in the document", it can also mean "debunked on the mailing list" or "dismissed out of hand as irrelevant". So your argument that there obviously isn't consensus doesn't actually hold up.

What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".

Not "there's a 60/40 split, therefore there's no consensus".

Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.

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.

I can't help but note two things:

* the IETF's approach predates 15 U.S.C. §4302 by more than a decade

* every single case example cited is US-American scoped¹ SDOs: American Society of Mechanical Engineers, National Fire Protection Association, American National Standards Institute²

¹ NB scope ≠ legal domicile. The IETF's legal status is… complicated… but does have US dependencies. Its scope is world-wide though. Not so for any of the mentioned entities, even if…

² …ANSI is a borderline case since it is the constituent ISO member. But still, it's the US entity.

I'm not trying to make a legal argument here, but… I'll say he shouldn't be trying to do that either. Most mathematicians and CS majors make very poor lawyers in any case, and often enough without any awareness of it.

Reply on news.ycombinator.com