Post #1249776

2026-04-15 06:58 UTC

@djb @pedromj @paulehoffman @rsalz We are discussing TLS specifically. Deployments are done by programming a list of supported key exchange algorithms, and negotiating one used by both sides. If you look at the IANA table, there are a lot of key exchanges already registered, including hybrids ECC+ML-KEM and the naked ML-KEM algorithm. All those can be deployed today, regardless of what the TLS WG does with ML-KEM draft. The discussion is about levels of endorsement and stability.

Replies (2)

@huitema@social.secret-wg.org 2026-04-15 07:05

@djb @pedromj @paulehoffman @rsalz In fact, there are many WG members arguing that we do not need an ML-KEM RFC since the NIST specification can just be deployed today. The counter to that argument is that publication as an RFC provides a stable reference, which helps interoperability, plus provides the IETF with a modicum of control. The counter to that counter argument is that RFC publication is mostly a marketing attempt, to make the algorithm easier to "sell".

Open ##1249777
@djb@mastodon.cr.yp.to 2026-04-15 07:28

@huitema @pedromj @paulehoffman @rsalz All WG-issued RFCs state that they represent "the consensus of the IETF community". The important effect of issuing an RFC, as opposed to a spec just sitting around somewhere, is IETF endorsement. This matters because endorsement often triggers usage. What happened for the non-hybrid-ML-KEM-in-TLS spec is a bunch of people (the majority of people who spoke up!) objecting to an RFC, most importantly because usage would violate common-sense security rules.

Open ##1249790