Hiya,

If this document proceeds, then I reckon it needs to be very specific
about the set of IANA TLS registries to which it applies, but that's
a detail.

Generally though, I'm in two minds about this, sorry;-) I think it's
"MUST NOT" (in section 3) is likely mostly good, but not absolutely.

Cases where the "MUST NOT" might not be best would include where some
group/ciphersuite is actually in very widespread use, in which case
there is (I think) a benefit in that being documented in an RFC along
with appropriate WG consensus caveats. (We had that case for SSH, but
the overall situation with TLS isn't the same.)

However, if the WG water down that "MUST NOT" I'm not sure how we'd
avoid debates like the current pure ml-kem WGLC or similar adoption
calls.

I don't know how to square that circle in the TLS WG. Maybe it needs
some RFC6919-like "NOT RECOMMENDED but we know you're doing it"
option for the value in the IANA registries:-)

Cheers,
S.

PS: I (of course:-) continue to think a security area BCP on which
PQ things are good to deploy now is the better approach that'd
avoid a bunch of these debates in individual WGs, but while there
seem to be a few people who agree with that, I don't see a big
rush of support for that position.


On 24/02/2026 00:55, Richard Barnes 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-
[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]

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to