Original text:
Abstract <del> This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries.  As a result, this document updates many RFCs (see updates header). </del>  1. 2. <del> This document requests that IANA make changes to a number of DTLS- and TLS-related IANA registries. </del>  <del> In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS. Add "TLS" to registries' names for consistency amongst TLS-related registries. Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. Add designated expert instructions as notes in the TLS ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS 1.3. Rename the NewSessionTicket TLS HandshakeType message registry entry RFC5077 to new_session_ticket to match the naming nomenclature for the other Handshake type names and to match with existing implementations. Rename the SessionTicket TLS extension to session_ticket to match the nomenclature for the other extensions' names. Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, TLS Certificate Types, TLS Supported Groups, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. Establish Designated Expert pool rules for Specification Required registries. </del>  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS <del> HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types RFC6961; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </del>  3. <del> IANA is to update the names of the following registries to add "TLS" to for consistency with the other TLS-related extensions: </del>  <del> Application-Layer Protocol Negotiation (ALPN) Protocol IDs, </del>  ExtensionType Values, <del> Heartbeat Message Types, </del>  <del> Heartbeat Modes, and </del>  <del> Supported Groups. IANA is also to add a reference to this document for the registry whose names have been updated as a result of the above change.  The remainder of this document will use the registry names with the "TLS" prefix. </del>  4. <del> Many of the TLS-related IANA registries were defined prior to RFC5226 where "IETF Consensus" was used instead of the RFC5226-defined "IETF Review".  To align with the new terminology, IANA is to update to use "IETF Review" in place of "IETF Consensus" in the following registries: </del>  <del> TLS Authorization Data Formats </del>  TLS Supplemental Data Formats (SupplementalDataType) with "IETF Consensus" are undergoing other changes either as a result of this document or I-D.ietf-tls-rfc4492bis.  5. The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are <del> consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". </del>  6. <del> IANA is to update the TLS ExtensionType Values registry as follows: </del>  Change the registry policy to: Values with the first byte in the range 0-254 (decimal) are <del> assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226. </del>  <del> Update the "References" to also refer to this document. </del>  Add the following note: <del> Note: Experts are to verify that there is in fact a publicly available standard. </del>  Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the <del> value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del>  7. <del> IANA is to update the TLS Cipher Suite registry as follows: </del>  <del> Change the registry policy to: </del>  <del> Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434. </del>  <del> Add a "Recommended" column to the cipher suite registry.  The </del>  cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards <del> Track document RFC5226 is required to register a cipher suite with </del>  the value "Yes". <del> Update the reference for this registry to also point to this document. </del>  <del> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2.  The notable exception are the ECDHE AES GCM cipher suites which are not yet standards track prior to the publication of this specification, but this document promotes those 4 cipher suites to standards track (see TO-DO insert reference). RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </del>  The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is AES CCM cipher suite names; those names are used here without modification. <del> Add the following: </del>  <del> WARNING: Cryptographic algorithms will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </del>  advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. <del> Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3. </del>  <del> Note(2): Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del>  <del> Note(3): The designated expert RFC5226 only ensures that the specification is publicly available. </del>  8. <del> Add a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls- rfc4492bis, which is standards track, are not marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is </del>  required to register an entry with the value "Yes".  The value 0 (0x0000) is to be marked as reserved. 9. <del> IANA is to update the TLS ClientCertificateType Identifiers registry as follows: Change the registry policy to: </del>  <del> Values in the range 0-223 are assigned via Specification Required RFC5226.  Values 224-255 are reserved for Private Use. </del>  <del> Add the following: </del>  <del> The designated expert RFC5226 only ensures that the specification </del>  is publicly available.  10. To align with TLS implementations and to align the naming <del> nomenclature for other Handshake message types, IANA is to rename entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)".  IANA is to also add a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </del>  11. <del> IANA is to add the following note to the TLS Exporter Label Registry: </del>  RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. <del> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del>  <del> IANA is also to add the following note: </del>  <del> The designated expert RFC5226 ensures that the specification is </del>  publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden.  12. <del> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): </del>  13. <del> Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC5226 is required to register a certificate type with the value "Yes". </del>  14. To make it clear that (D)TLS 1.3 has orphaned certain extensions <del> (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry: </del>  The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. <del> These are not applicable to DTLS 1.3. </del>  15. To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol <del> versions prior to 1.3), IANA is to: </del>  <del> Add the following to the TLS Compression Method Identifiers registry RFC3749: </del>  Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. <del> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </del>  The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. <del> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. </del>  <del> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del>  16. <del> Specification Required RFC5226 registry requests are registered after </del>  a three-week review period on the (tbd but maybe tls-reg- review@ietf.org) mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values

Reviewer comments:
A pretty major rewrite to incorporate the rationale for changes into individual sections as opposed to having it at the beginning. Also fixing some formatting.

Revised text:
Abstract  <ins> This document describes a number of changes to D/TLS 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 (D)TLS-related registries undertaken as part of the TLS1.3 development process.  This document updates many (D)TLS RFCs (see updates header). </ins> 1. 2.  <ins> This document instructs IANA to make changes to a number of (D)TLS- related IANA registries.  These changes were almost entirely motiviated by the development of TLS1.3 I-D.ietf-tls-tls13. </ins>  <ins> The changes introduced by this document range from simple, e.g., adding notes, to commplex, e.g., changing a registry's registration policy.  Intsead of listing the changes and their rationale in this, the introducotry, section each section provides rationale for the proposed change(s). </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS  <ins> HandshakeType I-D.ietf-tls-tls13, and TLS Certificate Status Types RFC6961 registries; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </ins> 3.  <ins> For consistency amongst TLS reqgistries, IANA [SHALL prepend/has prepended] "TLS" to the following registries: </ins>  <ins> Application-Layer Protocol Negotiation (ALPN) Protocol IDs RFC7301, </ins> ExtensionType Values,  <ins> Heartbeat Message Types RFC6520, and </ins>  <ins> Heartbeat Modes RFC6520. </ins>  <ins> IANA [SHALL update/has updated] the reference for these four registires to also refer to this document.  The remainder of this document will use the registry names with the "TLS" prefix. </ins> 4.  <ins> Many of the TLS-related IANA registries were defined prior to RFC8126 where "IETF Consensus" was used instead of the RFC8126-defined "IETF Review".  To align with the new terminology, IANA [SHALL update/has updated] the following registries to use "IETF Review" in place of "IETF Consensus": </ins>  <ins> TLS Authorization Data Formats RFC4680} </ins> TLS Supplemental Data Formats (SupplementalDataType) with "IETF Consensus" are undergoing other changes either as a result of this document or I-D.ietf-tls-rfc4492bis. <ins> IANA [SHALL update/has updated] the reference for these two registries to also refer to this document. </ins> 5. The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are  <ins> consistently identified in the registry, IANA: [SHALL rename/has renamed] entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 35. </ins> 6.  <ins> Experience has shown that the IETF Review registry policy for TLS Extensions was too strict.  Based on WG consensus, the decision was taken to change the registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry to: </ins> Change the registry policy to: Values with the first byte in the range 0-254 (decimal) are  <ins> assigned via Specification Required RFC8126.  Values with the first byte 255 (decimal) are reserved for Private Use RFC8126. </ins>  <ins> Update the "Reference" to also refer to this document. </ins> Add the following note:  <ins> Experts are to verify that there is in fact a publicly available standard. See expert-pool for additional information about the designated expert pool. Despite wanting to "loosen" the registration policies for TLS Extensions, it is still useful to indicate in the IANA registry which extensions the WG recommends be supported.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry to: </ins> Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the  <ins> value of the Recommended column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins> 7.  <ins> Experience has shown that the IETF Consensus registry policy for TLS Cipher Suites was too strict.  Based on WG consensus, the decision was taken to change the TLS Cipher Suite registry's registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS Cipher Suite registry's policy as follows: </ins>  <ins> See expert-pool for additional information about the designated expert pool. </ins>  <ins> The cipher suite registry has grown significantly and will continue to do so.  To better guide those not intimately involved in TLS, IANA [shall update/has updated] the TLS Cipher Suite registry as follows: </ins>  <ins> Add a "Recommended" column to the TLS Cipher Suite registry.  The </ins> cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards  <ins> Track document RFC8126 is required to register a cipher suite with </ins> the value "Yes".  <ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2. </ins>  <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is AES CCM cipher suite names; those names are used here without modification.  <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher suites.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </ins>  <ins> Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </ins> advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.  <ins> IANA [SHALL add/has added] the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 I-D.ietf-tls- tls13 uses the same registry but defines ciphers differently: Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3. </ins>  <ins> IANA [SHALL add/has added] the following notes to document the rules for populating the Recommended column: </ins>  <ins> Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. The designated expert RFC8126 only ensures that the specification is publicly available. IANA [SHALL uppdate/has updated] the reference for this registry to also refer to this document. </ins> 8.  <ins> Similar to cipher suites, supported groups have proliferated over time and some use the registry to measure implementations. Therefore, IANA [SHALL add/has added] a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls-rfc4492bis, which is standards track, are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS.  Future supported groups MUST define the value of this column.  A Standards Track document RFC8126 is </ins> required to register an entry with the value "Yes". <ins> IANA [SHALL add/has added] the following note: Supported Groups marked as "Yes" are those allocated via Standards Track RFCs.  Supported Groups marked as "No" are not; supported groups marked "No" range from "good" to "bad" from a cryptographic standpoint. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher supported.  Therefore, IANA [SHALL add/has added] the following warning to the registry: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> The value 0 (0x0000) is to be marked as reserved. 9.  <ins> Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifers is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS Cipher Suite registry's policy as follows: </ins>  <ins> See expert-pool for additional information about the designated expert pool. </ins>  <ins> IANA [SHALL add/has added] the following notes: </ins>  <ins> The designated expert RFC8126 only ensures that the specification </ins> is publicly available. <ins> ClientCertificateType Identifers marked as "Yes" are those allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not. </ins> 10. To align with TLS implementations and to align the naming  <ins> nomenclature with other Handshake message types, IANA: [SHALL rename/has renamed] entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </ins> 11.  <ins> To aid those reviewers who start with the IANA registry, IANA [SHALL add/has added]: The following note to the TLS Exporter Label Registry: </ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different.  <ins> A "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins>  <ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: </ins>  <ins> The designated expert RFC8126 ensures that the specification is </ins> publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden. <ins> Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> 12.  <ins> IANA [SHALL add/has added] the following entry to the TLS Alert Registry; the entry was omitted from the IANA instructions in RFC7301): </ins> 13.  <ins> Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC8126 is required to register a certificate type with the value "Yes".  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is required to register an entry with the value "Yes". See expert-pool for additional information about the designated expert pool. IANA [SHALL add/has added] the following note: Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer this document. </ins> 14. To make it clear that (D)TLS 1.3 has orphaned certain extensions  <ins> (i.e., some extensions are only applicable to version of (D)TLS prior to 1.3), IANA [SHALL add/has added] the following note to the TLS ExtensionType Values registry: </ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info.  <ins> These extensions are not applicable to (D)TLS 1.3. </ins> 15. To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol  <ins> versions prior to 1.3), IANA: </ins>  <ins> [SHALL add/has added] the following to the TLS Compression Method Identifiers registry RFC3749: </ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later.  <ins> [SHALL add/has added] the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3.  <ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to also refer to this document. </ins>  <ins> [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16.  <ins> Specification Required RFC8126 registry requests are registered after </ins> a three-week review period on the (tbd but maybe tls-reg- review@ietf.org) mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values