On Tue, Feb 24, 2026 at 06:05:56AM +0100, Nadim Kobeissi wrote: > Robert writes: > > I also know that I have customers that, despite our recommendations > > will want to 'pure' ML-KEM. > > If Cisco or Red Hat or whoever has big customers, or if some > government passes a regulation, that asks for TLS 1.3 to incorporate > Triple-DES as its symmetric cipher, then should the IETF be passing > drafts that accommodate this? > > If the answer is no, then why on Earth would we pass this draft here, > since it clearly breaks existing, studied, proven and deployed > compositional security guarantees? Because Red Hat has a big client? > Because some government asked for it?
The answer lies in the relevant codepoint registries having registration policies less onerous than Protocol Action. The relevant one is Specification Required, where "specification" need not be an RFC. The codepoints are registered, and the specification exists, therefore: the ship has sailed. This happened because long ago the IETF didn't want to be in the business of saying yes to some and no to other cryptographic algorithms from various the governments around the world. Now here we are and it's all :suprise-pikachu: that that decision amounts to saying "yes" to all those cryptographic algorithms from all the governments around the world. Well, yes, that was the point. If the IETF had kept these registries' policies as Protocol Action then we would definitely be able to say "no" to pure PQ ciphersuites, but then we'd be very uncomfortable telling some governments no, we'd get accused of having preferences (e.g., for the U.S. against Russia, or whatever), and... yeah we wouldn't like it, and soon we'd make the change to Specification Required. Basically: what you, DJB, and others want can't be had. The relevant choice was made long ago. It's too late to change this now, and honestly the IETF almost certainly does not want to change it because going back will inject too much international and domesting politics into the organization. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
