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".
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 -- [email protected]
To unsubscribe send an email to [email protected]
