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

[Blumenthal, Uri - 0553 - MITLL]

Respectfully disagree (autocorrector tried to change “Respectfully” to “Tragically “ - I wonder why 😁). We all know that these algorithms will be used by a non-negligible group. Might as well accept that now, and make the future transition easier.  — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory On Feb 23, 2026, at 21:12, Eric Rescorla <e...@rtfm.com> 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.  ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory.   ZjQcmQRYFpfptBannerEnd 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 <u...@ll.mit.edu> 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...@rtfm.com> 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 <durumcrustu...@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. * 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...@rtfm.com> wrote: On Mon, Feb 23, 2026 at 5:47 PM Deirdre Connolly <durumcrustu...@gmail.com> 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...@rtfm.com> 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 <r...@ipv.sx> 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: <internet-dra...@ietf.org> 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 <r...@ipv.sx> 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 -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org