Draft: draft-ietf-tls-iana-registry-updates

Commentary: 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 .
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).
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).
This document requests that IANA make changes to a number of DTLS-
and TLS-related IANA registries.
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.
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
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.
Application-Layer Protocol Negotiation (ALPN) Protocol IDs,
Heartbeat Message Types,
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.
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.
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).
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
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.
Application-Layer Protocol Negotiation (ALPN) Protocol IDs
RFC7301,
Heartbeat Modes RFC6520.
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.
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
consistently identified in the registry, IANA is to rename entry 35
to "session_ticket (renamed from "SessionTicket TLS")".
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 RFC5226.
Update the "References" to also refer to this document.
Note: Experts are to verify that there is in fact a publicly
available standard.
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
value of this column.  A Standards Track document RFC5226 is
required to register an extension with the value "Yes".
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.
Add a "Recommended" column to the cipher suite registry.  The
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
Track document RFC5226 is required to register a cipher suite with
the value "Yes".
Update the reference for this registry to also point to this
document.
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.
IANA [SHALL update/has updated] the reference for these two
registries to also refer to this document.
Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required RFC8126.  Values with the
first byte 255 (decimal) are reserved for Private Use RFC8126.
Update the "Reference" to also refer to this document.
Experts are to verify that there is in fact a publicly available
standard.
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
value of the Recommended column.  A Standards Track document
RFC8126 is required to register an extension with the value "Yes".
Add a "Recommended" column to the TLS Cipher Suite registry.  The
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
Track document RFC8126 is required to register a cipher suite with
the value "Yes".
The cipher suites that follow are standards track server-
authenticated (and optionally client-authenticated) cipher suites
which are currently available in TLS 1.2.
RFC EDITOR: The previous paragraph is for document reviewers and is
not
meant for the registry.
WARNING: Cryptographic algorithms 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.
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.
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.
Note(3): The designated expert RFC5226 only ensures that the
specification is publicly available.
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
required to register an entry with the value "Yes".
Values in the range 0-223 are assigned via Specification Required
RFC5226.  Values 224-255 are reserved for Private Use.
The designated expert RFC5226 only ensures that the specification
is publicly available.
To align with TLS implementations and to align the naming
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.
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".
The designated expert RFC5226 ensures that the specification is
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.
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".
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.
These are not applicable to DTLS 1.3.
Update the "References" in the TLS Compression Method Identifiers,
TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to
also refer to this document.
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".
Specification Required RFC5226 registry requests are registered after
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
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.
RFC EDITOR: The previous paragraph is for document reviewers and is
not meant for the registry.
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.
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.
IANA [SHALL uppdate/has updated] the reference for this registry to
also refer to this document.
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
required to register an entry with the value "Yes".
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.
ClientCertificateType Identifers marked as "Yes" are those
allocated via Standards Track RFCs.  ClientCertificateTypes marked
as "No" are not.
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".
The designated expert RFC8126 ensures that the specification is
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.
Exporters Labels marked as "Yes" are those allocated via Standards
Track RFCs.  Exporter Labels marked as "No" are not.
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".
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.
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.
These extensions are not applicable to (D)TLS 1.3.
Specification Required RFC8126 registry requests are registered after
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
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.