]> Cisco

rlb@ipv.sx

Security Transport Layer Security next generation unicorn sparkling distributed ledger 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction There used to be a grand tradition of debating the merits of cryptographic algorithms in the TLS working group. Over time, folks realized that this was not a productive use of the WG's time. The typical TLS WG participant is not a cryptographer, and the cryptographic choices of TLS users are typically dictated by other factors than the opinion of the TLS WG. As a result, loosened the registration policy on the TLS registries to Specification Required, with a very limited carve-outs related to the "Recommended" column. As a result, anyone can register a code point for a cryptographic algorithm with a stable public specification, without having to convince the TLS WG of anything. Registration is as simple as one email to iana@iana.org. This document proposes that the TLS WG adopt a restrictive policy that if the only thing a document does could be done without the WG, that document will not be adopted.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

When Are Crypto Documents OK? The registry policies in 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

Unless a document does one of these things it MUST NOT be adopted by the WG. Even if there are additional technical details to be specified, the proponents can publish their own specification; even an individual -00 Internet-draft meets IANA's criteria for a stable, public specification. For example:

• and define technical details, but do not request Recommended=Y. The authors could have simply published these details on their own (e.g., in an individual Internet-draft) and requested code points.
• simply registers SLH-DSA code points, pointing to the existing FIPS documents for all technical details. Nonetheless, it has consumed a significant amount of WG time, including multiple challenges and appeals.

Authors that just want to register a code point should skip the working group and go directly to IANA. It's easier, it's faster, and it won't waste a bunch of other folks' time in the working group.

Security Considerations The policy proposed in this document has no impact on security. The registry policies already allow any algorithm with a specification to be registered. Let's just not spend the WG's time debating things that the WG doesn't need to opine on.

IANA Considerations This document has no IANA actions. Ironically.

References Normative References This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References SandboxAQ This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. DigiCert Google Cloudflare This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. Nokia DigiCert Entrust Limited Cisco Systems This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3.