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

[Watson Ladd <[e-mail]>]

On Mon, Feb 23, 2026 at 3:26 PM Robert Relyea
<rrelyea=[e-mail]> wrote:
>
> On 2/20/26 5:38 PM, Viktor Dukhovni wrote:
> > I support publication as a stable reference for the already allocated
> > code point that sports multiple implementations.
>
> I support publication as well, for exactly Vikor's reason.
>
> There is some feeling that publication == endorsement. Almost all the
> arguments against is 'hybrid is better, so it should be preferred'. I
> agree that is the case. I also know that I have customers that, despite
> our recommendations will want to 'pure' ML-KEM.
>
> The fact is the exact same thing will be carried out independent of this
> acceptance:
>
> We (and other libraries) will end up implementing this draft (whether it
> is published or not), and making 'pure' ML-KEM default off and require
> work to turn it on. We now (and will continue) to default to hybrid
> x25519mlkem as our preferred algorithm (and have since before that draft
> was approved).
>
> Publishing the draft simple means "If you must do this, this is how".

The codepoint registration is all you need for that.
>
> >
> > At least for OpenSSL, I don't expect publication to shift the needle
> > from "implemented" to "enabled by default" (in clients and servers).
> > The pure ML-KEM groups are not included in the default supported groups
> > list and there are no plans to change that.  For a pure ML-KEM group to
> > be used as the source of the key agreement shared secret it needs to be
> > explicitly enabled on **both** ends and preferred by whichever side's
> > preference order is taken into account by the server.
> >
> > Meanwhile, the X25519MLKEM768 hybrid has been enabled by default for
> > almost a year, and will surely continue to be far more common in
> > practice.
> >
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim