[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-07 (Ends 2026-02-27)

[Nadim Kobeissi <[e-mail]>]

If the code points already exist then why can’t we just follow Richard Barnes’ proposal: 

https://mailarchive.ietf.org/arch/msg/tls/Xenvf8TDxwodCZuEfKh81op93_A/

I express support for it here under the understanding that these would be its outcomes:

https://mailarchive.ietf.org/arch/msg/tls/h1VZn2qPNWfAdh8iwYvcfMT9Ghg/

Plus, I support ML-KEM-only key agreement having its own code points! This is because as far as I’m aware, these code points exist because at some point in the future, we may indeed become confident enough in ML-KEM to switch to pure ML-KEM and away from hybrids. But that point doesn’t seem to be in 2026, and RLWE primitives such as ML-KEM deserve more scrutiny both on the maths and on the implementation before this switch occurs.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 24 Feb 2026, at 6:42 AM, Nico Williams <[e-mail]> wrote:
> 
> 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
> --