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? Isn’t the IETF supposed to be passing drafts that are strictly in the benefit of humanity and not drafts that exist because if they’re passed, a big corporation stands to get lucrative contracts or because a government simply wants them for no clear reason? Nadim Kobeissi Symbolic Software • https://symbolic.software > On 24 Feb 2026, at 12:26 AM, Robert Relyea > <[email protected]> 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". > >> >> 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
