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 So the question for the PQ-only algorithms is not whether the IETF can prevent deployment (it cannot), but whether publishing these algorithms as RFCs is necessary or harmful. There is consensus that it is not necessary, since the IANA registrations do not require it. What we see is mostly a debate on whether it is harmful, because it would help promoting an unproven algorithm that might be compromised. This is where opinions vary.
Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz I've been tracking the arguments and counterarguments (see https://blog.cr.yp.to/20260221-structure.html for a chart) and I don't see where you're getting this "promoting" idea from. Both sides of the debate want to roll out PQ to try to stop quantum attacks. The difference is that one side says you're allowed to replace ECC with _just_ PQ, whereas the other side is requiring ECC+PQ (at negligible extra cost) to reduce the damage caused by more failures of PQ security.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz By promoting, I meant "publication as an RFC would help the marketing (or promotion) of the PQ-only approach by actors linked to the US government." As in, "of course you can do that, the IETF published it as an RFC, do not look at the fine print."
Show threadDaniel J. BernsteinApr 14
@huitema @paulehoffman @rsalz It's important to distinguish the non-controversial part (rolling out a PQ layer) from the controversial part (_removing_ the existing ECC layer rather than _supplementing_ the existing ECC layer). Saying that the objection is to "promoting an unproven algorithm" misunderstands what's actually at issue. Same for lumping both parts together into a combined "approach" and saying the objection is to that.
Show threadChristian HuitemaApr 14
@djb @paulehoffman @rsalz I don't understand what you mean by "removing". The hybrid key exchanges are defined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/, which went through IETF last call and is in the final stage of approval by the IESG. I don't know that anybody is proposing to remove that.
Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

This draft defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie- Hellman) exchange.

IETF Datatracker
Show threadDaniel J. Bernstein
@huitema @paulehoffman @rsalz Let's try an example. Google and Cloudflare used CECPQ2b = ECC+SIKE for tens of millions of user connections, instead of the usual ECC. That wasn't _removing_ ECC in favor of SIKE; it was _supplementing_ ECC with SIKE. This is why the break of SIKE still left those connections with the usual security of ECC. If they had instead incompetently _removed_ ECC and replaced that with SIKE, the SIKE attack would have immediately broken all of those connections.
Apr 15 at 3:46amWeb