4 ms·

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 mo

by eqvinox 3mo ago

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-parameters.xhtml#tls-parameters-8 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 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?]

ekr____ 3mo ago
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/ 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.
- eqvinox 3mo ago
  > […] "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 :)
- eqvinox 3mo ago
  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.
  - ekr____ 3mo ago
    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-have-been-an-email/ 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.
    - eqvinox 3mo ago
      Thanks for the link to that amazing document!
ButlerianJihad 3mo ago
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.)
- LastTrain 3mo ago
  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
- eqvinox 3mo ago
  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 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 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.)
phasmantistes 3mo ago
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 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.
- eqvinox 3mo ago
  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.

by eqvinox 3mo ago

ekr____ 3mo ago

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

eqvinox 3mo ago
> […] "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 :)
eqvinox 3mo ago
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.
- ekr____ 3mo ago
  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-have-been-an-email/ 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.
  - eqvinox 3mo ago
    Thanks for the link to that amazing document!

ButlerianJihad 3mo ago

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

LastTrain 3mo ago
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
eqvinox 3mo ago
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 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 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.)

phasmantistes 3mo ago

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

eqvinox 3mo ago
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.