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 threadPedroMJApr 14
@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.
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 threadDaniel J. Bernstein
@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?
Apr 15 at 3:53amWeb