Oh ho ho so we do need RFCs! 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]
