IANA Registry Updates for TLS and DTLSTableau Softwarejoe@salowey.netsn3rdsean@sn3rd.com
Security
TLS WGInternet-DraftThis 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).As the authors of this draft are also the WG chairs, the responsible
Area Director has agreed to judge consensus.RFC EDITOR: Please delete section prior to publication.This document instructs IANA to make changes to a number of
(D)TLS-related IANA registries. These changes were almost entirely
motivated by the development of TLS1.3 .The changes introduced by this document range from simple, e.g., adding
notes, to complex, e.g., changing a registry’s registration policy.
Instead of listing the changes and their rationale in this, the
introductory, section each section provides rationale for the proposed
change(s).This document proposes no changes to the registration policies for TLS
Alert , TLS ContentType ,
TLS HandshakeType , and TLS Certificate Status
Types 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.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.For consistency amongst TLS registries, IANA
[SHALL prepend/has prepended] “TLS” to the following registries:Application-Layer Protocol Negotiation (ALPN) Protocol IDs ,ExtensionType Values,Heartbeat Message Types , andHeartbeat Modes .IANA [SHALL update/has updated] the reference for these four registries
to also refer to this document. The remainder of this document will
use the registry names with the “TLS” prefix.Many of the TLS-related IANA registries were defined prior to
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”:TLS Authorization Data Formats TLS Supplemental Data Formats (SupplementalDataType) This is not a universal change as some registries originally defined
with “IETF Consensus” are undergoing other changes either as a result
of this document or .IANA [SHALL update/has updated] the reference for these two registries
to also refer to this document.The instructions in this document add a Recommended column to many of
the TLS registries to indicate parameters that are generally recommended
for implementations to support. Adding a recommended parameter to a
registry or updating a parameter to recommended status requires
standards action. Not all parameters defined in standards track
documents need to be marked as recommended.If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability, or
is intended only for specific use cases.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:[SHALL rename/has renamed] entry 35 to “session_ticket (renamed from
“SessionTicket TLS”)” .[SHALL add/has added] a reference to this document in the Reference
column for entry 35.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
while reserving a small part of the code space for
experimental and private use. Therefore, IANA [SHALL update/has
updated] the TLS ExtensionType Values registry to:Change the registry policy to:
Values with the first byte in the range 0-254 (decimal) are assigned
via Specification Required . Values with the first byte
255 (decimal) are reserved for Private Use .Update the “Reference” to also refer to this document.Add the following notes:
Experts are to verify that there is in fact a publicly available
standard. An Internet Draft that is posted and never published or a
standard in another standards body, industry consortium, university
site, etc. suffices.
As specified in , assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.See 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: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. In order to register an extension with the value
“Yes”, a Standards Track document is REQUIRED. IESG
action is REQUIRED for a Yes->No transition.ExtensionRecommendedserver_nameYesmax_fragment_lengthYesclient_certificate_urlYestrusted_ca_keysYestruncated_hmacYesstatus_requestYesuser_mappingYesclient_authzNoserver_authzNocert_typeYessupported_groupsYesec_point_formatsYessrpNosignature_algorithmsYesuse_srtpYesheartbeatYesapplication_layer_protocol_negotiationYesstatus_request_v2Yessigned_certificate_timestampNoclient_certificate_typeYesserver_certificate_typeYespaddingYesencrypt_then_macYesextended_master_secretYessession_ticketYesrenegotiation_infoYes
The following is from and is included here to
ensure aligment between these specifications. also uses the TLS ExtensionType Registry originally
created in . IANA has updated it to reference this
document. The registry and its allocation policy is listed below:IANA [SHALL update/has updated] this registry to include the
“key_share”, “pre_shared_key”, “psk_key_exchange_modes”,
“early_data”, “cookie”, “supported_versions”,
“certificate_authorities”, “oid_filters”, “post_handshake_auth”,
and “signature_algorithms_certs”, extensions with the values
defined in this document and the Recommended value of “Yes”.IANA [SHALL update/has updated] this registry to include a “TLS
1.3” column which lists the messages in which the extension may
appear. This column [SHALL be/has been] initially populated from
the table in Section 4.2 of with any
extension not listed there marked as “-“ to indicate that it is not
used by TLS 1.3.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 while reserving a small part of
the code space for experimental and private use. Therefore, IANA
[SHALL update/has updated] the TLS Cipher Suite registry’s policy as
follows:See for additional information about the designated
expert pool.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: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. In order to register
an extension with the value “Yes, a Standards Track document
is REQUIRED. IESG action is REQUIRED for a Yes->No
transition.
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.The cipher suites that follow are standards track ephemeral pre-shared
key cipher suites which are available in TLS 1.2. is
inconsistent with respect to the ordering of components within PSK AES
CCM cipher suite names; those names are used here without modification.RFC EDITOR: The previous paragraph is for document reviewers and is not
meant for the registry.Despite the following behavior being misguided, experience has shown
that some customers use the IANA registry as checklist against which
to measure an implementation’s completeness and some implementers
blindly implement cipher suites. 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 add/has added] the following note to ensure that those that
focus on IANA registries are aware that TLS 1.3
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.IANA [SHALL add/has added] the following notes to document the rules
for populating the Recommended column:
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.
CCM_8 cipher suites are not marked as recommended. These cipher
suites have a significantly truncated authentication tag that represents
a security trade-off that may not be appropriate for general
environments.IANA [SHALL add/has added] the following notes for additional
information:
The designated expert only ensures that the specification
is publicly available. An Internet Draft that is posted and never
published or a standard in another standards body, industry consortium,
university site, etc. suffices.
As specified in , assignments made in the Private Use
space are not generally useful for broad interoperability. It is the
responsibility of those making use of the Private Use range to ensure
that no conflicts occur (within the intended scope of use). For
widespread experiments, temporary reservations are available.IANA [SHALL update/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
, which is standards track, are marked as
“Yes”; these groups apply to TLS 1.3 and
previous versions of TLS. Future supported groups MUST define the value
of this column. In order to register an extension with the value “Yes”,
a Standards Track document is REQUIRED. IESG action is
REQUIRED for a Yes->No transition.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.
The designated expert only ensures that the specification
is publicly available. An Internet Draft that is posted and never
published or a standard in another standards body, industry consortium,
university site, etc. suffices.Despite the following behavior being misguided, experience has shown
that some customers use the IANA registry as checklist against which
to measure an implementation’s completeness and some implementers
blindly implement groups 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.The value 0 (0x0000) is to be marked as reserved.Experience has shown that the IETF Consensus registry policy for TLS
ClientCertificateType Identifiers is too strict. Based on WG
consensus, the decision was taken to change registration policy to
Specification Required 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:See for additional information about the designated
expert pool.IANA [SHALL add/has added] the following notes:
The designated expert only ensures that the specification
is publicly available. An Internet Draft that is posted and never
published or a standard in another standards body, industry consortium,
university site, etc. suffices.
As specified in , assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
ClientCertificateType Identifiers marked as “Yes” are those allocated
via Standards Track RFCs. ClientCertificateTypes marked as “No” are
not.To align with TLS implementations and to align the naming 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)” .[SHALL add/has added] a reference to this document in the Reference
column for entry 4 in the TLS HandshakeType registry.To aid those reviewers who start with the IANA registry, IANA [SHALL
add/has added]:The following note to the TLS Exporter Label Registry: defines keying material exporters for TLS in terms of
the TLS PRF. replaced the PRF with HKDF, thus
requiring a new construction. The exporter interface remains the same,
however the value is computed different.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. In order to register an extension with the value “Yes”, a
Standards Track document is REQUIRED. IESG action is
REQUIRED for a Yes->No transition.To provide additional information for the designated experts, IANA
[SHALL add/has added] the following note:
The designated expert ensures that the specification is
publicly available. An Internet Draft that is posted and never
published or a standard in another standards body, industry consortium,
university site, etc. suffices. 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.IANA [SHALL update/has updated] the reference for this registry to also
refer to this document.IANA [SHALL add/has added] the following entry to the TLS Alert
Registry; the entry was omitted from the IANA instructions in
: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
while reserving a small part of the code space for
experimental and private 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”. In order to register an extension with
the value “Yes”, a Standards Track document is REQUIRED.
Future Certificate Types MUST define the value of this column. A
Standards Track document is REQUIRED to register an
entry with the value “Yes”. IESG action is REQUIRED for a Yes->No
transition.See 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.To make it clear that (D)TLS 1.3 has orphaned certain extensions (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:
The following extensions are only applicable to (D)TLS protocol
versions prior to 1.3: trusted_ca_keys, truncated_hmac, user_mapping,
cert_type, 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.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 versions prior
to 1.3), IANA:[SHALL add/has added] the following to the TLS Compression Method
Identifiers registry :
Value 0 (NULL) is the only value in this registry applicable to (D)TLS
protocol version 1.3 or later.[SHALL add/has added] the following to the TLS HashAlgorithm
and TLS SignatureAlgorithm registries :
The values in this registry are only applicable to (D)TLS protocol
versions prior to 1.3.[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.[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”.Despite the fact that the HashAlgorithm and SignatureAlgorithm
registries are orphaned, it is still import to warn implementers of
pre-TLS1.3 implementations about the dangers of blinding implementing
cryptographic algorithms. Therefore, IANA [SHALL add/has added] the
following warning to the HashAlgorithm and SignatureAlgorithm:
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.Specification Required registry requests are registered
after a three-week review period on the 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.Registration requests sent to the mailing list for review SHOULD use an
appropriate subject (e.g., “Request to register value in TLS bar
registry”).Within the review period, the Designated Experts will either approve or
deny the registration request, communicating this decision to the review
list and IANA. Denials SHOULD include an explanation and, if applicable,
suggestions as to how to make the request successful. Registration
requests that are undetermined for a period longer than 21 days can be
brought to the IESG’s attention (using the iesg@ietf.org mailing list)
for resolution.Criteria that SHOULD be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability
or useful only for a single application, and whether the registration
description is clear.IANA MUST only accept registry updates from the Designated Experts and
SHOULD direct all requests for registration to the review mailing list.It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using this
specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert SHOULD defer to the judgment of the other Experts.The change to Specification Required from IETF Review lowers the amount
of review provided by the WG for cipher suites and supported groups.
This change reflects reality in that the WG essentially provided no
cryptographic review of the cipher suites or supported groups. This
was especially true of national cipher suites.Recommended algorithms are regarded as secure for general use at the
time of registration, however, cryptographic algorithms and parameters
will be broken or weakened over time. It is possible that the
recommended status in the registry lags behind the most recent advances
in cryptanalysis. Implementers and users need to check that the
cryptographic algorithms listed continue to provide the expected level
of security.Designated experts ensure the specification is publicly available. They may
provide more in depth reviews. Their review should not be taken as an
endorsement of the cipher suite, extension, supported group, etc.This document is entirely about changes to TLS-related IANA registries.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Transport Layer Security (TLS) Application-Layer Protocol Negotiation ExtensionThis document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat ExtensionThis document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.TLS Handshake Message for Supplemental DataThis specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]Transport Layer Security (TLS) Authorization ExtensionsThis document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.Transport Layer Security (TLS) Session Resumption without Server-Side StateThis document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]AES-CCM Cipher Suites for Transport Layer Security (TLS)This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]Keying Material Exporters for Transport Layer Security (TLS)A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]Transport Layer Security Protocol Compression MethodsThe Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]The Transport Layer Security (TLS) Multiple Certificate Status Request ExtensionThis document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and EarlierThis document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Digital Signature Algorithm (EdDSA) as authentication mechanisms. This document obsoletes and replaces RFC 4492.Transport Layer Security (TLS) ExtensionsThis document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]