> 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?
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]
