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.

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

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

@darkuncle Sorry to see you promoting this. He's done great work, but this whole thread is crazy conspiracy thinking.
@djb @darkuncle no I do not, but that does not mean that the NSA is corrupting the IETF.
@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?
@djb @darkuncle I presumed nothing. Read what I wrote. Twisting words to win an argument. Your better than this Dan.
@rsalz @djb Do you have any evidence of that last statement, Rich?

@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

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

@djb @huitema @paulehoffman @rsalz the analogy is of course ridiculously broken because everyone is building towards and expecting the future to be PQ only.

A better comparison is a scenario where we mandate hybrid cars because perhaps EV technology will fail in the future, even though we know eventually everyone will drive a pure EV.

Some people now prefer gas, some hybrid, some EV. We let people choose because non of the car variants are dangerous.

You are trying to force hybrid cars on everyone because you think EV might break despite years of research of the worlds best experts.

@letoams @huitema @paulehoffman @rsalz Requiring seatbelts in cars reduces the damage to humans from car crashes. Requiring ECC along with PQ reduces the damage to the users from PQ security failures.

Saying that people are trying to prevent PQ failures doesn't break this analogy. People are also trying to prevent car crashes.

I'm unable to decipher your attempt to draw another analogy: e.g., I can't figure out whether "perhaps EV technology will fail" is sticking to the topic of _safety_.

@letoams @huitema @paulehoffman @rsalz I do understand that your attempted analogy somehow involves decisions between gas vehicles, electric vehicles, and hybrids. But those have major cost differences, whereas the cost of PQ (which is dominated by communication cost for typical PQ choices) is so close to the cost of ECC+PQ that we've been seeing comic levels of failure to find _any_ application that can't afford to keep the ECC part.
@letoams @huitema @paulehoffman @rsalz ML-KEM-768 has 1184-byte public keys and 1088-byte ciphertexts. Bleeding-edge ML-DSA-44 has 1312-byte public keys and 2420-byte signatures. It ends up sounding pretty damn stupid to complain about the extra cost of also continuing to send 32-byte ECC keys and 32-byte ECC ciphertexts.