Daniel J. BernsteinApr 10
The IETF TLS chairs have now issued a "last call" for objections to non-hybrid signatures in TLS. Do they admit that their previous "last call" re non-hybrid KEMs ended up with a _majority_ in opposition, and that many opposition statements obviously also apply to signatures? No.
Show threadARGVMI~1.PIFApr 10

@djb

Why do they want non-hybrid KEMs and signatures, anyway? Seems like a bad idea to protect all of everything with nothing but unproven crypto.

Show threadDaniel J. BernsteinApr 10

@argv_minus_one I have an introductory chart https://blog.cr.yp.to/20260221-structure.html showing the arguments and counterarguments.

Most common argument from proponents: NSA is asking for non-hybrids, ergo support non-hybrids. This argument works for (1) companies chasing NSA money, (2) companies that take any excuse for extra options as a barrier to entry for competitors, and (3) people who think that "NSA Cybersecurity" isn't a conduit for https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf but rather an independent pro-security agency.

Show threadrsalzApr 10
@darkuncle Sorry to see you promoting this. He's done great work, but this whole thread is crazy conspiracy thinking.
Show threadDaniel J. BernsteinApr 10
@rsalz @darkuncle You think https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf is a conspiracy theory?
Show threadrsalzApr 10
@djb @darkuncle no I do not, but that does not mean that the NSA is corrupting the IETF.
Show threadDaniel J. BernsteinApr 11
@rsalz @darkuncle Let me see if I understand. You're agreeing that NSA has a large budget to sabotage "standards and specification for commercial public key technologies" etc., but you presume that this doesn't include IETF, since the document doesn't _specifically_ name IETF? Also, just checking: by the same logic, you presume that this doesn't include ISO? NIST? IEEE? When we recommend proactive steps to protect SDOs against sabotage, you accuse us of being crazy conspiracy theorists?
Show threadrsalzApr 11
@djb @darkuncle I presumed nothing. Read what I wrote. Twisting words to win an argument. Your better than this Dan.
Show threadPaul HoffmanApr 11
@rsalz @djb Do you have any evidence of that last statement, Rich?
Show threadDaniel J. BernsteinApr 13

@paulehoffman @rsalz Paul, great to see you showing up here!

We're currently discussing Rich's delusion that NSA doesn't attack IETF. On that topic, can you please state for the record how much NSA paid you for your promotion of TLS randomness extensions in IETF (https://web.archive.org/web/20260331174508/https://sockpuppet.org/blog/2015/08/04/is-extended-random-malicious/)? Or are you denying that this happened?

Also, do you dispute https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/checkoway saying that Dual EC becomes thousands of times cheaper to attack whenever those randomness extensions are deployed?

Is Extended Random A Malicious NSA Plot? — Quarrelsome

Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz I don't know for 2012, but from 2013 on a large number of IETF participants were absolutely convinced of being under attack. It was fairly obvious that some IETF participants were either willing enablers of these attacks, or "useful idiots". But we don't know which ones, and we quickly realized that launching a witch-hunt would be very destructive, and that the safest path was to keep discussions strictly technical.
Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz Using ECC+PQ instead of non-hybrid PQ is a straightforward, low-cost, broadly recommended, broadly deployed technical step to limit the damage from PQ security failures (such as the SIKE break and KyberSlash). The problem at hand is non-technical, namely NSA pressuring various companies such as Cisco to support non-hybrid PQ. See https://blog.cr.yp.to/20251004-weakened.html#tls for quotes from employees of NSA and Cisco admitting this.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz The political problem is complex. First, there is a wide consensus in the IETF for not standing in the way of deployments, and in particular not using IETF processes to block IANA registration except in some very specific registers -- because blockades generate various kinds of smuggling that end up very counter-productive in general.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz The IETF has a strong bent towards "publishing rather than censoring", unless the technical flaws are obvious. That bent drives strongly towards "publishing with some proper warning in the text", while not publishing at all would be pretty extraordinary, especially in presence of a constituency that really want to sell products to the US government. So at that stage of the debate, the issue is really about how strong the warning should be.
Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz We require seatbelts in cars to reduce the number and severity of injuries in the event of a crash. The problem with allowing seatbelts to be skipped is something we explain to 6-year-olds. No, we don't allow cars to be sold with warnings in place of seatbelts. And, no, we don't allow the seatbelt rules to be corrupted by funding from the National Morgue Association.
Show threadPedroMJApr 13
@djb @huitema @paulehoffman @rsalz The problem discussed in this thread can be amended with a new prescriptive draft that states the potentially undesired outcomes and that specifies the means to avoid them.
Show threadChristian HuitemaApr 13
@pedromj @djb @paulehoffman @rsalz I am really not sure that publishing more words would help counter propaganda by the bad faith actors that Dan fears. If the WG does decide to publish the ML-KEM TLS draft, strong warnig would help somewhat. Changing the registration option of the hybrid key exchange algorithms to recommended=Y would also help. But propaganda is countered by public speech, not so much by standard actions.
Show threadPedroMJ
@huitema @djb @paulehoffman @rsalz Some one cannot force other one to add the warning to their I-D, but can write the warning in a new I-D and find enough support for it to make the previous I-D to integrate the new I-D ---hence adding the warnin---, or live separately to help engineers know about the problem.
Apr 14 at 8:49amMastodon for Android
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz Actually, working groups can pressure for changes in a draft. Once a draft is accepted by a working group, the status of the authors change. They are not the only one in charge of the text anymore. What they write must reflect the consensus of the WG, and if that consensus includes adding a warning, they have to do that.
Show threadPedroMJApr 14
@huitema @djb @paulehoffman @rsalz I know this, but one must be active in a WG to convince enough members to vote for something like adding some text. It is not easy to be so active sporadically. It is much more feasible to write concerns in an I-D ---a formal document with familiar structure--- and discuss it in some MLs and/or meetings.
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz We are heading towards a situation where the ML-KEM key exchange draft will be published, probably in about a year. I would much prefer to see a warning in the text itself, and I think that can be achieved. After that, the IETF will have published 2 documents, hybrid ML-KEM and naked ML-KEM. If we follow Dan's reasoning, we can expect the US Gov to encourage "naked", which they might be able to break. We will be in the domain of opinions, not standards.
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz After publication of naked ML-KEM, we could try to sway opinion by publishing Internet drafts such a "naked ML-KEM considered harmful". We could lobby browser vendors to not implement that. We could publish in news papers, rally suppport from the EFF, etc. All that may help getting people to deploy hybryd ML-KEM instead. But it would help more if there is an warning in the naked ML-KEM draft itself.
Show threadrsalzApr 14
@huitema @pedromj I'll assume you read the draft and the PR with the revised security considerations. You also know that pushing on social media doesn't much impact IETF, unless you're trying to do brigading which I do not think you are.
Show threadChristian HuitemaApr 15
@rsalz @pedromj At that point, I am commenting on the IETF process, much as I would be commenting on the weather. If Pedro wants to influence the result, he should definitely work in the WG -- waiting on the sideline and publishing a "considered harmful" draft will be much less effective.
Show threadChristian HuitemaApr 15
@rsalz @pedromj As for the security considerations, I think it will take some iterations before converging. And yes, the exact content is best discussed on the TLS mailing list.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz You're confused. The normal way to deploy post-quantum KEMs is _already_ as a second layer _on top_ of ECC. See the long list of examples at the top of https://blog.cr.yp.to/20251004-weakened.html. What NSA has been trying to do is pay for IETF endorsement of a weaker alternative that removes ECC.
Show threadChristian HuitemaApr 15
@djb @pedromj @paulehoffman @rsalz We are discussing TLS specifically. Deployments are done by programming a list of supported key exchange algorithms, and negotiating one used by both sides. If you look at the IANA table, there are a lot of key exchanges already registered, including hybrids ECC+ML-KEM and the naked ML-KEM algorithm. All those can be deployed today, regardless of what the TLS WG does with ML-KEM draft. The discussion is about levels of endorsement and stability.
Show threadChristian HuitemaApr 15
@djb @pedromj @paulehoffman @rsalz In fact, there are many WG members arguing that we do not need an ML-KEM RFC since the NIST specification can just be deployed today. The counter to that argument is that publication as an RFC provides a stable reference, which helps interoperability, plus provides the IETF with a modicum of control.
The counter to that counter argument is that RFC publication is mostly a marketing attempt, to make the algorithm easier to "sell".
Show threadChristian HuitemaApr 15
@djb @pedromj @paulehoffman @rsalz Easier to sell is pretty much the same as "Endorsement by the IETF". At that point, the technical arguments boil down to the risk that ML-KEM is found broken. Dan, you argue that that risk is very high because the promotion efforts are orchestrated by the government. But if people were to discard your argument, we are left with a generic discussion of risk. That discussion could result in having a recommendation=Y for hybrids versus no for naked. Maybe.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz Now you're just making things up. https://blog.cr.yp.to/20251004-weakened.html gives concrete examples, such as SIKE and KyberSlash, to illustrate the PQ security risks. https://cr.yp.to/papers.html#qrcsp gives many more examples. Instead of responding to _any_ of these examples, you grossly mischaracterize what I'm saying as "that risk is very high because the promotion efforts are orchestrated by the government". Of course, you don't give a URL.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz The core issue is endorsement. It isn't about having a stable reference; having a stable reference doesn't need an RFC. It isn't about interoperability; interoperability doesn't need an RFC. The "control" argument is circular; https://archive.cr.yp.to/2026-04-10/05:38:16/1w0wAgKE9fiKZKunAg8qCyVyWYZ4j-aHgW-0aFDzgcw/https/mailarchive.ietf.org/arch/msg/tls/LqG-gHxgRvVPebE3m28D8VT7dN4/ spells this out in baby steps.
Show threadPaul Wouters 🇪🇺🇨🇦Apr 15

@djb @huitema @pedromj @paulehoffman @rsalz funny you used the exact opposite argument for ssh sntrup761x25519-sha512, arguing a code point wasn’t enough - despite even already being almost universally available in a vendor namespace. You just wanted the “endorsement” of an RFC.

Cherry pickers will cherry pick 🍒

Show threadDaniel J. BernsteinApr 16

@letoams @huitema @pedromj @paulehoffman @rsalz The basic dividing line is very simple: I endorse various _good_ things. I oppose endorsement of various _bad_ things.

I'm not the one here issuing a confusing mixture of (1) acknowledging "strong consensus that pure PQ should not be recommended at this time", (2) claiming that it's good to issue RFCs on "pure" (non-hybrid) PQ, and (3) claiming that such RFCs wouldn't be endorsement despite prominently claiming "consensus of the IETF community".

Show threadPaul Wouters 🇪🇺🇨🇦Apr 17
@djb @huitema @pedromj @paulehoffman @rsalz
Show threadDaniel J. BernsteinApr 15

@huitema @pedromj @paulehoffman @rsalz All WG-issued RFCs state that they represent "the consensus of the IETF community". The important effect of issuing an RFC, as opposed to a spec just sitting around somewhere, is IETF endorsement. This matters because endorsement often triggers usage.

What happened for the non-hybrid-ML-KEM-in-TLS spec is a bunch of people (the majority of people who spoke up!) objecting to an RFC, most importantly because usage would violate common-sense security rules.

Show threadrsalzApr 14
@huitema You think it will be published? I'm not sure sure it has consensus.
Show threadChristian HuitemaApr 15
@rsalz Not that I specially want to, but yes I assume that after a couple more months of discussion the naked ML-KEM draft will be published. This is not certain, but that's the most likely outcome. This is not like the visibility draft, for which there was a plurality of "strongly oppose". This kind of debate typically ends with a compromise, such as OK to publish if the opponents get a strongly enough wording in the security section, or maybe in the intro.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz The previous "last call" for objections to the _non-hybrid_ ML-KEM spec produced objections from 22 people and support from 21 people. Names, quotes, links: https://blog.cr.yp.to/20260405-votes.html This is obviously very far from the "consensus of the IETF community" that every WG-issued RFC claims to have. Are you really claiming that IETF will issue this as an RFC? Why do you claim this?
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz The burden is the other way from what you're describing. The WG can't issue non-consensual RFCs. Conflicts must be resolved by a process of open review and discussion; if they aren't resolved then issuing an RFC would violate IETF rules for how WGs operate. It's not merely that the authors have to add a warning if there's consensus on a warning. There's no default entitlement for documents to sail through.