In fact, IANA has already registered code points for pure ML-KEM, based on the individual draft that led to draft-ietf-tls-mlkem.
See entries 512, 513, and 514 of the TLS Supported Groups registry. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 Between that registration and the details in the cited draft-connolly-tls-mlkem-key-agreement-05, no further TLS work is required to make these KEMs usable. On Mon, Feb 23, 2026 at 4:11 PM Eric Rescorla <[email protected]> wrote: > Whether we publish the document or not has no bearing on whether > these algorithms are usable. The code points are already registered. > > At the point where we think that the IETF ought to recommend them > (Recommended=Y), then we can publish an RFC. > > -Ekr > > > > On Mon, Feb 23, 2026 at 6:05 PM Blumenthal, Uri - 0553 - MITLL < > [email protected]> wrote: > >> I think declining to publish draft-ietf-tls-mlkem is a bad idea, and >> strongly suggest that the WG dis publish it. Because non-hybrid PQ KEMs are >> needed, and in the long term only they make sense. >> — >> Regards, >> Uri >> >> Secure Resilient Systems and Technologies >> MIT Lincoln Laboratory >> >> On Feb 23, 2026, at 20:59, Eric Rescorla <[email protected]> wrote: >> >> >> On Mon, Feb 23, 2026 at 5: 52 PM Deirdre Connolly <durumcrustulum@ >> gmail. com> wrote: Oh ho ho so we do need RFCs! Sometimes. As Section 3 >> says: The registry policies in [RFC8447] define a few specific things that >> require working group action. >> ZjQcmQRYFpfptBannerStart >> This Message Is From an External Sender >> This message came from outside the Laboratory. >> >> ZjQcmQRYFpfptBannerEnd >> >> On Mon, Feb 23, 2026 at 5:52 PM Deirdre Connolly < >> [email protected]> wrote: >> >>> Oh ho ho so we do need RFCs! >>> >> >> Sometimes. As Section 3 says: >> >> The registry policies in [RFC8447] define a few specific things that >> require working group action. >> >> * Initial registration with Recommended=Y >> >> * Changing the value of the Recommended column to "Y" or "D" from >> something else >> >> * Changing the value of the Recommended column from "Y" or "D" to >> something else >> >> The point is that we don't otherwise need RFCs. >> >> -Ekr >> >> >> >>> On Mon, Feb 23, 2026 at 8:51 PM Eric Rescorla <[email protected]> wrote: >>> >>>> >>>> >>>> On Mon, Feb 23, 2026 at 5:47 PM Deirdre Connolly < >>>> [email protected]> wrote: >>>> >>>>> > If others agree that this is a good policy, then I think we should >>>>> enact >>>>> i> t with retroactive effect, which is to say: >>>>> >>>>> > 1. Make ECHDE/MLKEM Recommended=Y (as also suggested by >>>>> Bas's draft). >>>>> > 2. Decline to publish draft-ietf-tls-mlkem >>>>> >>>>> Why not claw back -ecdhe-mlkem? >>>>> >>>> >>>> That would be another alternative, but I think it should be >>>> Recommended=Y and >>>> that requires an RFC at Standards Track. >>>> >>>> -Ekr >>>> >>>> >>>>> >>>>> On Mon, Feb 23, 2026 at 8:03 PM Eric Rescorla <[email protected]> wrote: >>>>> >>>>>> I strongly support this draft. One of the main reasons for relaxing >>>>>> the >>>>>> registration rules and introducing the Recommended column was to >>>>>> avoid spending time debating the merits of new algorithms that >>>>>> everyone >>>>>> knew weren't going to be standardized, and yet a huge fraction of the >>>>>> mail on the list over the past few months is doing precisely that. >>>>>> >>>>>> The obvious objection to this draft is that there might be some work >>>>>> required to refine how an algorithm is used and that an I-D might not >>>>>> be >>>>>> enough for that. I have two responses to that: >>>>>> >>>>>> - Recent history does not seem to indicate that is the case. We're >>>>>> busily debating parts of the specification that have no impact on >>>>>> the wire format. >>>>>> - If an algorithm isn't important enough to have Recommended=Y, >>>>>> then it's not worth WG time to refine it. >>>>>> >>>>>> If others agree that this is a good policy, then I think we should >>>>>> enact >>>>>> it with retroactive effect, which is to say: >>>>>> >>>>>> 1. Make ECHDE/MLKEM Recommended=Y (as also suggested by >>>>>> Bas's draft). >>>>>> 2. Decline to publish draft-ietf-tls-mlkem >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> On Mon, Feb 23, 2026 at 4:56 PM Richard Barnes <[email protected]> wrote: >>>>>> >>>>>>> Hi TLS folks, >>>>>>> >>>>>>> Those who have worked with me know that I hate doing unnecessary >>>>>>> work. It occurred to me that the TLS WG has been doing a lot of >>>>>>> unnecessary work on drafts that just register crypto algorithms. This >>>>>>> draft proposes that we shouldn't do that. >>>>>>> >>>>>>> Submitted for your consideration, >>>>>>> --Richard >>>>>>> >>>>>>> ---------- Forwarded message --------- >>>>>>> From: <[email protected]> >>>>>>> Date: Mon, Feb 23, 2026 at 2:53 PM >>>>>>> Subject: New Version Notification for >>>>>>> draft-barnes-tls-this-could-have-been-an-email-00.txt >>>>>>> To: Richard Barnes <[email protected]> >>>>>>> >>>>>>> >>>>>>> A new version of Internet-Draft >>>>>>> draft-barnes-tls-this-could-have-been-an-email-00.txt has been >>>>>>> successfully >>>>>>> submitted by Richard Barnes and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-barnes-tls-this-could-have-been-an-email >>>>>>> Revision: 00 >>>>>>> Title: Stop Doing Cryptographic Algorithm Drafts when Email to >>>>>>> IANA is All You Need >>>>>>> Date: 2026-02-24 >>>>>>> Group: Individual Submission >>>>>>> Pages: 5 >>>>>>> URL: >>>>>>> https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-email/ >>>>>>> HTML: >>>>>>> https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.html >>>>>>> HTMLized: >>>>>>> https://datatracker.ietf.org/doc/html/draft-barnes-tls-this-could-have-been-an-email >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> >>>>>>> People keep pitching drafts to the TLS Working Group where the >>>>>>> only >>>>>>> thing the draft does is register a code point for a cryptographic >>>>>>> algorithm. Stop doing that. It's unnecessary. Write an email to >>>>>>> IANA instead. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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] >>>>>> >>>>> _______________________________________________ >> 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
