[TLS] Re: [EXT] Re: Fwd: New Version Notification for draft-barnes-tls-this-could-have-been-an-email-00.txt

[Eric Rescorla <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> wrote:
>>
>>>
>>>
>>> On Mon, Feb 23, 2026 at 5:47 PM Deirdre Connolly <
>>> [e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: <[e-mail]>
>>>>>> 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 <[e-mail]>
>>>>>>
>>>>>>
>>>>>> 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 -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>