rfc8447v1.txt   rfc8447.txt 
Internet Engineering Task Force (IETF) J. Salowey Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 8447 Tableau Software Request for Comments: 8447 Tableau Software
Updates: 3749, 5077, 4680, 5246, 5705, S. Turner Updates: 3749, 5077, 4680, 5246, 5705, S. Turner
5878, 6520, 7301 sn3rd 5878, 6520, 7301 sn3rd
Category: Standards Track August 2018 Category: Standards Track August 2018
ISSN: 2070-1721 ISSN: 2070-1721
IANA Registry Updates for Transport Layer Security (TLS) IANA Registry Updates for TLS and DTLS
and Datagram Transport Layer Security (DTLS)
Abstract Abstract
This document describes a number of changes to TLS and DTLS IANA This document describes a number of changes to TLS and DTLS IANA
registries that range from adding notes to the registry all the way registries that range from adding notes to the registry all the way
to changing the registration policy. These changes were mostly to changing the registration policy. These changes were mostly
motivated by WG review of the TLS- and DTLS-related registries motivated by WG review of the TLS- and DTLS-related registries
undertaken as part of the TLS 1.3 development process. undertaken as part of the TLS 1.3 development process.
This document updates the following RFCs: 3749, 5077, 4680, 5246, This document updates the following RFCs: 3749, 5077, 4680, 5246,
skipping to change at page 2, line 11 skipping to change at page 2, line 11
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3 3. Adding "TLS" to Registry Names . . . . . . . . . . . . . . . 3
4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3 4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3
5. Adding Recommended Column . . . . . . . . . . . . . . . . . . 4 5. Adding "Recommended" Column . . . . . . . . . . . . . . . . . 4
6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4 6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4 7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4
8. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 7 8. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 7
9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 9 9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 9
10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 10 10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 10
11. New Session Ticket TLS Handshake Message Type . . . . . . . . 11 11. New Session Ticket TLS Handshake Message Type . . . . . . . . 11
12. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 12 12. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 12
13. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 13 13. Adding Missing Item to TLS Alert Registry . . . . . . . . . . 13
14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 13 14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 13
15. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 14 15. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 14
16. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 14 16. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 14
17. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 15 17. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 15
18. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 16 18. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 16
19. Security Considerations . . . . . . . . . . . . . . . . . . . 17 19. Security Considerations . . . . . . . . . . . . . . . . . . . 17
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
21.1. Normative References . . . . . . . . . . . . . . . . . . 17 21.1. Normative References . . . . . . . . . . . . . . . . . . 17
21.2. Informative References . . . . . . . . . . . . . . . . . 19 21.2. Informative References . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 15 skipping to change at page 3, line 15
of their scarcity. of their scarcity.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Add "TLS" to Registry Names 3. Adding "TLS" to Registry Names
For consistency amongst TLS registries, IANA has prepended "TLS" to For consistency amongst TLS registries, IANA has prepended "TLS" to
the following registries: the following registries:
o Application-Layer Protocol Negotiation (ALPN) Protocol IDs o Application-Layer Protocol Negotiation (ALPN) Protocol IDs
[RFC7301], [RFC7301],
o ExtensionType Values, o ExtensionType Values,
o Heartbeat Message Types [RFC6520], and o Heartbeat Message Types [RFC6520], and
skipping to change at page 4, line 5 skipping to change at page 4, line 5
o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878] o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]
This is not a universal change, as some registries originally defined This is not a universal change, as some registries originally defined
with "IETF Consensus" are undergoing other changes either as a result with "IETF Consensus" are undergoing other changes either as a result
of this document or [RFC8422]. of this document or [RFC8422].
IANA has updated the reference for these two registries to also refer IANA has updated the reference for these two registries to also refer
to this document. to this document.
5. Adding Recommended Column 5. Adding "Recommended" Column
Per this document, a Recommended column has been added to many of the Per this document, a "Recommended" column has been added to many of
TLS registries to indicate parameters that are generally recommended the TLS registries to indicate parameters that are generally
for implementations to support. Adding a Recommended parameter to a recommended for implementations to support. Adding a "Recommended"
registry or updating a parameter to Recommended status requires parameter (i.e., "Y") to a registry or updating a parameter to
Standards Action. Not all parameters defined in Standards Track "Recommended" status requires Standards Action. Not all parameters
documents need to be marked as Recommended. defined in Standards Track documents need to be marked as
"Recommended".
If an item is not marked as Recommended, it does not necessarily mean If an item is not marked as "Recommended" (i.e., "N"), it does not
that it is flawed; rather, it indicates that the item either has not necessarily mean that it is flawed; rather, it indicates that the
been through the IETF consensus process, has limited applicability, item either has not been through the IETF consensus process, has
or is intended only for specific use cases. limited applicability, or is intended only for specific use cases.
6. Session Ticket TLS Extension 6. Session Ticket TLS Extension
The nomenclature for the registry entries in the TLS ExtensionType The nomenclature for the registry entries in the TLS ExtensionType
Values registry correspond to the presentation language field name Values registry correspond to the presentation language field name
except for entry 35. To ensure that the values in the registry are except for entry 35. To ensure that the values in the registry are
consistently identified in the registry, IANA: consistently identified in the registry, IANA:
o has renamed entry 35 to "session_ticket" (renamed from o has renamed entry 35 to "session_ticket" (renamed from
"SessionTicket TLS")" [RFC5077]. "SessionTicket TLS")" [RFC5077].
skipping to change at page 5, line 12 skipping to change at page 5, line 12
See Section 18 for additional information about the designated expert See Section 18 for additional information about the designated expert
pool. pool.
Despite wanting to "loosen" the registration policies for TLS Despite wanting to "loosen" the registration policies for TLS
extensions, it is still useful to indicate in the IANA registry which extensions, it is still useful to indicate in the IANA registry which
extensions the WG recommends be supported. Therefore, IANA has extensions the WG recommends be supported. Therefore, IANA has
updated the TLS ExtensionType Values registry to: updated the TLS ExtensionType Values registry to:
o Add a "Recommended" column with the contents as listed below. o Add a "Recommended" column with the contents as listed below.
This table has been generated by marking Standards Track RFCs as This table has been generated by marking Standards Track RFCs as
"Yes" and all others as "No". Future extensions MUST define the "Y" and all others as "N". Future extensions MUST define the
value of the Recommended column. In order to register an value of the "Recommended" column. In order to register an
extension with the value "Yes", a Standards Track document extension with the value "Y", a document produced through
[RFC8126] is REQUIRED. IESG Approval is REQUIRED for a Yes->No Standards Action [RFC8126] is REQUIRED. IESG Approval is REQUIRED
transition. for a Y->N transition.
+----------------------------------------+-------------+ +----------------------------------------+-------------+
| Extension | Recommended | | Extension | Recommended |
+----------------------------------------+-------------+ +----------------------------------------+-------------+
| server_name | Yes | | server_name | Y |
| | | | | |
| max_fragment_length | Yes | | max_fragment_length | N |
| | | | | |
| client_certificate_url | Yes | | client_certificate_url | Y |
| | | | | |
| trusted_ca_keys | Yes | | trusted_ca_keys | Y |
| | | | | |
| truncated_hmac | Yes | | truncated_hmac | Y |
| | | | | |
| status_request | Yes | | status_request | Y |
| | | | | |
| user_mapping | Yes | | user_mapping | Y |
| | | | | |
| client_authz | No | | client_authz | N |
| | | | | |
| server_authz | No | | server_authz | N |
| | | | | |
| cert_type | No | | cert_type | N |
| | | | | |
| supported_groups | Yes | | supported_groups | Y |
| | | | | |
| ec_point_formats | Yes | | ec_point_formats | Y |
| | | | | |
| srp | No | | srp | N |
| | | | | |
| signature_algorithms | Yes | | signature_algorithms | Y |
| | | | | |
| use_srtp | Yes | | use_srtp | Y |
| | | | | |
| heartbeat | Yes | | heartbeat | Y |
| | | | | |
| application_layer_protocol_negotiation | Yes | | application_layer_protocol_negotiation | Y |
| | | | | |
| status_request_v2 | Yes | | status_request_v2 | Y |
| | | | | |
| signed_certificate_timestamp | No | | signed_certificate_timestamp | N |
| | | | | |
| client_certificate_type | Yes | | client_certificate_type | Y |
| | | | | |
| server_certificate_type | Yes | | server_certificate_type | Y |
| | | | | |
| padding | Yes | | padding | Y |
| | | | | |
| encrypt_then_mac | Yes | | encrypt_then_mac | Y |
| | | | | |
| extended_master_secret | Yes | | extended_master_secret | Y |
| | | | | |
| cached_info | Yes | | cached_info | Y |
| | | | | |
| session_ticket | Yes | | session_ticket | Y |
| | | | | |
| renegotiation_info | Yes | | renegotiation_info | Y |
+----------------------------------------+-------------+ +----------------------------------------+-------------+
IANA has added the following notes: IANA has added the following notes:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc., suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the extension. should not be taken as an endorsement of the extension.
Note: As specified in [RFC8126], assignments made in the Private Use Note: As specified in [RFC8126], assignments made in the Private Use
space are not generally useful for broad interoperability. It is space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use). ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available. For widespread experiments, temporary reservations are available.
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases. limited applicability, or is intended only for specific use cases.
Note: token_binding is omitted from the above table; [TOKBIND] Note: token_binding is omitted from the above table; [TOKBIND]
specifies the Recommended column for this extension. specifies the "Recommended" column for this extension.
Note: The following is from [RFC8446] and is included here to ensure Note: The following is from [RFC8446] and is included here to ensure
alignment between these specifications. alignment between these specifications.
[RFC8446] also uses the TLS ExtensionType Values registry originally [RFC8446] also uses the TLS ExtensionType Values registry originally
created in [RFC4366]. IANA has updated it to reference this created in [RFC4366]. IANA has updated it to reference this
document. The registry and its allocation policy are listed below: document. The registry and its allocation policy are listed below:
o IANA has updated this registry to include the "key_share", o IANA has updated this registry to include the "key_share",
"pre_shared_key", "psk_key_exchange_modes", "early_data", "pre_shared_key", "psk_key_exchange_modes", "early_data",
"cookie", "supported_versions", "certificate_authorities", "cookie", "supported_versions", "certificate_authorities",
"oid_filters", "post_handshake_auth", and "oid_filters", "post_handshake_auth", and
"signature_algorithms_certs" extensions with the values defined in "signature_algorithms_certs" extensions with the values defined in
this document and the Recommended value of "Yes". this document and the "Recommended" value of "Y".
o IANA has updated this registry to include a "TLS 1.3" column that o IANA has updated this registry to include a "TLS 1.3" column that
lists the messages in which the extension may appear. This column lists the messages in which the extension may appear. This column
has been initially populated from the table in Section 4.2 of has been initially populated from the table in Section 4.2 of
[RFC8446] with any extension not listed there marked as "-" to [RFC8446] with any extension not listed there marked as "-" to
indicate that it is not used by TLS 1.3. indicate that it is not used by TLS 1.3.
8. TLS Cipher Suite Registry 8. TLS Cipher Suite Registry
Experience has shown that the IETF Consensus registry policy for TLS Experience has shown that the IETF Consensus registry policy for TLS
skipping to change at page 7, line 46 skipping to change at page 7, line 46
first byte 255 (decimal) are reserved for Private Use [RFC8126]. first byte 255 (decimal) are reserved for Private Use [RFC8126].
See Section 18 for additional information about the designated expert See Section 18 for additional information about the designated expert
pool. pool.
The TLS Cipher Suite registry has grown significantly and will The TLS Cipher Suite registry has grown significantly and will
continue to do so. To better guide those not intimately involved in continue to do so. To better guide those not intimately involved in
TLS, IANA has updated the TLS Cipher Suite registry as follows: TLS, IANA has updated the TLS Cipher Suite registry as follows:
o Add a "Recommended" column to the TLS Cipher Suite registry. The o Add a "Recommended" column to the TLS Cipher Suite registry. The
cipher suites that follow in the two tables are marked as "Yes". cipher suites that follow in the two tables are marked as "Y".
All other cipher suites are marked as "No". Future cipher suites All other cipher suites are marked as "N". Future cipher suites
MUST define the value of the Recommended column. In order to MUST define the value of the "Recommended" column. In order to
register an extension with the value "Yes", a Standards Track register an extension with the value "Y", a document produced
document [RFC8126] is REQUIRED. IESG Approval is REQUIRED for a through Standards Action [RFC8126] is REQUIRED. IESG Approval is
Yes->No transition. REQUIRED for a Y->N transition.
o The cipher suites that follow are Standards Track server- o The cipher suites that follow are Standards Track server-
authenticated (and optionally client-authenticated) cipher suites authenticated (and optionally client-authenticated) cipher suites
that are currently available in TLS 1.2. that are currently available in TLS 1.2.
Cipher Suite Name | Value Cipher Suite Name | Value
----------------------------------------------+------------ ----------------------------------------------+------------
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}
skipping to change at page 9, line 16 skipping to change at page 9, line 16
IANA registries are aware that TLS 1.3 [RFC8446] uses the same IANA registries are aware that TLS 1.3 [RFC8446] uses the same
registry but defines ciphers differently: registry but defines ciphers differently:
Note: Although TLS 1.3 uses the same cipher suite space as previous Note: Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently, versions of TLS, TLS 1.3 cipher suites are defined differently,
only specifying the symmetric ciphers, and cannot be used for TLS only specifying the symmetric ciphers, and cannot be used for TLS
1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be
used with TLS 1.3. used with TLS 1.3.
IANA has added the following notes to document the rules for IANA has added the following notes to document the rules for
populating the Recommended column: populating the "Recommended" column:
Note: CCM_8 cipher suites are not marked as Recommended. These Note: CCM_8 cipher suites are not marked as "Recommended". These
cipher suites have a significantly truncated authentication tag cipher suites have a significantly truncated authentication tag
that represents a security trade-off that may not be appropriate that represents a security trade-off that may not be appropriate
for general environments. for general environments.
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases. limited applicability, or is intended only for specific use cases.
IANA has added the following notes for additional information: IANA has added the following notes for additional information:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc., suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the cipher suite. should not be taken as an endorsement of the cipher suite.
Note: As specified in [RFC8126], assignments made in the Private Use Note: As specified in [RFC8126], assignments made in the Private Use
space are not generally useful for broad interoperability. It is space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use). ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available. For widespread experiments, temporary reservations are available.
IANA has updated the reference for this registry to also refer to IANA has updated the reference for this registry to also refer to
this document. this document.
9. TLS Supported Groups 9. TLS Supported Groups
Similar to cipher suites, supported groups have proliferated over Similar to cipher suites, supported groups have proliferated over
time, and some use the registry to measure implementations. time, and some use the registry to measure implementations.
Therefore, IANA has added a "Recommended" column with a "Yes" for Therefore, IANA has added a "Recommended" column with a "Y" for
secp256r1, secp384r1, x25519, and x448, while all others are "No". secp256r1, secp384r1, x25519, and x448, while all others are "N".
These "Yes" groups are taken from Standards Track RFCs; [RFC8422] These "Y" groups are taken from Standards Track RFCs; [RFC8422]
elevates secp256r1 and secp384r1 to Standards Track. Not all groups elevates secp256r1 and secp384r1 to Standards Track. Not all groups
from [RFC8422], which is Standards Track, are marked as "Yes"; these from [RFC8422], which is Standards Track, are marked as "Y"; these
groups apply to TLS 1.3 [RFC8446] and previous versions of TLS. groups apply to TLS 1.3 [RFC8446] and previous versions of TLS.
Future supported groups MUST define the value of this column. In Future supported groups MUST define the value of this column. In
order to register an extension with the value "Yes", a Standards order to register an extension with the value "Y", a document
Track document [RFC8126] is REQUIRED. IESG Approval is REQUIRED for produced through Standards Action [RFC8126] is REQUIRED. IESG
a Yes->No transition. Approval is REQUIRED for a Y->N transition.
IANA has added the following note: IANA has added the following note:
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases. limited applicability, or is intended only for specific use cases.
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc., suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the supported group. should not be taken as an endorsement of the supported group.
Despite the following behavior being misguided, experience has shown Despite the following behavior being misguided, experience has shown
that some customers use the IANA registry as a checklist against that some customers use the IANA registry as a checklist against
which to measure an implementation's completeness, and some which to measure an implementation's completeness, and some
implementers blindly implement groups supported. Therefore, IANA has implementers blindly implement groups supported. Therefore, IANA has
added the following warning to the registry: added the following warning to the registry:
WARNING: Cryptographic algorithms and parameters will be broken or WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing cipher suites listed weakened over time. Blindly implementing cipher suites listed
here is not advised. Implementers and users need to check that here is not advised. Implementers and users need to check that
skipping to change at page 11, line 17 skipping to change at page 11, line 17
Values in the range 0-223 are assigned via Specification Required Values in the range 0-223 are assigned via Specification Required
[RFC8126]. Values 224-255 are reserved for Private Use. [RFC8126]. Values 224-255 are reserved for Private Use.
See Section 18 for additional information about the designated expert See Section 18 for additional information about the designated expert
pool. pool.
IANA has added the following notes: IANA has added the following notes:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc., suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the identifier. should not be taken as an endorsement of the identifier.
Note: As specified in [RFC8126], assignments made in the Private Use Note: As specified in [RFC8126], assignments made in the Private Use
space are not generally useful for broad interoperability. It is space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use). ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available. For widespread experiments, temporary reservations are available.
Note: ClientCertificateType Identifiers marked as "Yes" are those Note: ClientCertificateType Identifiers marked as "Y" are those
allocated via Standards Track RFCs. ClientCertificateTypes marked allocated via Standards Track RFCs. ClientCertificateTypes marked
as "No" are not. as "N" are not.
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that necessarily mean that it is flawed; rather, it indicates that
either the item has not been through the IETF consensus process, either the item has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use has limited applicability, or is intended only for specific use
cases. cases.
11. New Session Ticket TLS Handshake Message Type 11. New Session Ticket TLS Handshake Message Type
To align with TLS implementations and to align the naming To align with TLS implementations and to align the naming
nomenclature with other Handshake message types, IANA: nomenclature with other Handshake message types, IANA:
skipping to change at page 12, line 19 skipping to change at page 12, line 19
o The following note to the TLS Exporter Label registry: o The following note to the TLS Exporter Label registry:
Note: [RFC5705] defines keying material exporters for TLS in terms Note: [RFC5705] defines keying material exporters for TLS in terms
of the TLS PRF. [RFC8446] replaced the PRF with HKDF, thus of the TLS PRF. [RFC8446] replaced the PRF with HKDF, thus
requiring a new construction. The exporter interface remains the requiring a new construction. The exporter interface remains the
same; however, the value is computed differently. same; however, the value is computed differently.
o A "Recommended" column to the TLS Exporter Label registry. The o A "Recommended" column to the TLS Exporter Label registry. The
table that follows has been generated by marking Standards Track table that follows has been generated by marking Standards Track
RFCs as "Yes" and all others as "No". Future exporters MUST RFCs as "Y" and all others as "N". Future exporters MUST define
define the value of this column. In order to register an the value of this column. In order to register an extension with
extension with the value "Yes", a Standards Track document the value "Y", a document produced through Standards Action
[RFC8126] is REQUIRED. IESG Approval is REQUIRED for a Yes->No [RFC8126] is REQUIRED. IESG Approval is REQUIRED for a Y->N
transition. transition.
Exporter Value | Recommended | Exporter Value | Recommended |
--------------------------------|-------------| --------------------------------|-------------|
client finished | Yes | client finished | Y |
server finished | Yes | server finished | Y |
master secret | Yes | master secret | Y |
key expansion | Yes | key expansion | Y |
client EAP encryption | Yes | client EAP encryption | Y |
ttls keying material | No | ttls keying material | N |
ttls challenge | No | ttls challenge | N |
EXTRACTOR-dtls_srtp | Yes | EXTRACTOR-dtls_srtp | Y |
EXPORTER_DTLS_OVER_SCTP | Yes | EXPORTER_DTLS_OVER_SCTP | Y |
EXPORTER: teap session key seed | Yes | EXPORTER: teap session key seed | Y |
The following notes provide additional information for the designated To provide additional information for the designated experts, IANA
experts. has added the following notes:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc. suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the exporter. The expert also verifies should not be taken as an endorsement of the exporter. The expert
that the label is a string consisting of printable ASCII also verifies that the label is a string consisting of printable
characters beginning with "EXPORTER". IANA MUST also verify that ASCII characters beginning with "EXPORTER". IANA MUST also verify
one label is not a prefix of any other label. For example, labels that one label is not a prefix of any other label. For example,
"key" or "master secretary" are forbidden. labels "key" or "master secretary" are forbidden.
Note: Exporters Labels marked as "Yes" are those allocated via
Standards Track RFCs. Exporter Labels marked as "No" are not.
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that necessarily mean that it is flawed; rather, it indicates that
either the item has not been through the IETF consensus process, either the item has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use has limited applicability, or is intended only for specific use
cases. cases.
IANA has updated the reference for this registry to also refer to IANA has updated the reference for this registry to also refer to
this document. this document.
13. Add Missing Item to TLS Alert Registry 13. Adding Missing Item to TLS Alert Registry
IANA has added the following entry to the TLS Alert registry; the IANA has added the following entry to the TLS Alert registry; the
entry was omitted from the IANA instructions in [RFC7301]: entry was omitted from the IANA instructions in [RFC7301]:
120 no_application_protocol Y [RFC7301] RFC 8447 120 no_application_protocol Y [RFC7301] [RFC8447]
14. TLS Certificate Types 14. TLS Certificate Types
Experience has shown that the IETF Consensus registry policy for TLS Experience has shown that the IETF Consensus registry policy for TLS
Certificate Types is too strict. Based on WG consensus, the decision Certificate Types is too strict. Based on WG consensus, the decision
was taken to change registration policy to Specification Required was taken to change registration policy to Specification Required
[RFC8126] while reserving a small part of the code space for [RFC8126] while reserving a small part of the code space for
experimental and private use. Therefore, IANA has changed the TLS experimental and private use. Therefore, IANA has changed the TLS
Certificate Types registry to: Certificate Types registry to:
o Change the registry policy to: o Change the registry policy to:
Values with the first byte in the range 0-223 (decimal) are Values with the first byte in the range 0-223 (decimal) are
assigned via Specification Required [RFC8126]. Values with the assigned via Specification Required [RFC8126]. Values with the
first byte 224-255 (decimal) are reserved for Private Use first byte 224-255 (decimal) are reserved for Private Use
[RFC8126]. [RFC8126].
o Add a "Recommended" column to the registry. X.509 and Raw Public o Add a "Recommended" column to the registry. X.509 and Raw Public
Key are "Yes". All others are "No". In order to register an Key are "Y". All others are "N". In order to register an
extension with the value "Yes", a Standards Track document extension with the value "Y", a Standards Track document [RFC8126]
[RFC8126] is REQUIRED. Future Certificate Types MUST define the is REQUIRED. Future Certificate Types MUST define the value of
value of this column. A Standards Track document [RFC8126] is this column. A Standards Track document [RFC8126] is REQUIRED to
REQUIRED to register an entry with the value "Yes". IESG Approval register an entry with the value "Y". IESG Approval is REQUIRED
is REQUIRED for a Yes->No transition. for a Y->N transition.
See Section 18 for additional information about the designated expert See Section 18 for additional information about the designated expert
pool. pool.
IANA has added the following note: IANA has added the following note:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet-Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc. suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in-depth reviews, but their approval should not be The expert may provide more in-depth reviews, but their approval
taken as an endorsement of the certificate type. should not be taken as an endorsement of the certificate type.
Note: If an item is not marked as Recommended, it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that necessarily mean that it is flawed; rather, it indicates that
either the item has not been through the IETF consensus process, either the item has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use has limited applicability, or is intended only for specific use
cases. cases.
IANA has updated the reference for this registry to also refer this IANA has updated the reference for this registry to also refer this
document. document.
15. Orphaned Extensions 15. Orphaned Extensions
skipping to change at page 15, line 17 skipping to change at page 15, line 13
values are registered in the TLS SignatureScheme registry. values are registered in the TLS SignatureScheme registry.
o has updated the "Reference" field in the TLS Compression Method o has updated the "Reference" field in the TLS Compression Method
Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm
registries to also refer to this document. registries to also refer to this document.
o has updated the TLS HashAlgorithm registry to list values 7 and o has updated the TLS HashAlgorithm registry to list values 7 and
9-223 as "Reserved" and the TLS SignatureAlgorithm registry to 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to
list values 4-6 and 9-223 as "Reserved". list values 4-6 and 9-223 as "Reserved".
o has added the following to the TLS ClientCertificateType
Identifiers registry [RFC5246]:
Note: Note: The values in this registry are only applicable to
(D)TLS protocol versions prior to 1.3.
Despite the fact that the HashAlgorithm and SignatureAlgorithm Despite the fact that the HashAlgorithm and SignatureAlgorithm
registries are orphaned, it is still important to warn implementers registries are orphaned, it is still important to warn implementers
of pre-TLS1.3 implementations about the dangers of blindly of pre-TLS1.3 implementations about the dangers of blindly
implementing cryptographic algorithms. Therefore, IANA has added the implementing cryptographic algorithms. Therefore, IANA has added the
following warning to the HashAlgorithm and SignatureAlgorithm: following warning to the HashAlgorithm and SignatureAlgorithm:
WARNING: Cryptographic algorithms and parameters will be broken or WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing the cryptographic weakened over time. Blindly implementing the cryptographic
algorithms listed here is not advised. Implementers and users algorithms listed here is not advised. Implementers and users
need to check that the cryptographic algorithms listed continue to need to check that the cryptographic algorithms listed continue to
skipping to change at page 15, line 49 skipping to change at page 15, line 51
Note: As specified in [RFC8126], assignments made in the Private Use Note: As specified in [RFC8126], assignments made in the Private Use
space are not generally useful for broad interoperability. It is space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use). ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available. For widespread experiments, temporary reservations are available.
IANA has added the following notes to the TLS PskKeyExchangeMode IANA has added the following notes to the TLS PskKeyExchangeMode
registry: registry:
Note: If an item is not marked as Recommended it does not Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that necessarily mean that it is flawed; rather, it indicates that
either the item has not been through the IETF consensus process, either the item has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use has limited applicability, or is intended only for specific use
cases. cases.
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. An Internet Draft that is posted and never publicly available. It's sufficient to have an Internet-Draft
published or a standard in another standards body, industry (that is posted and never published as an RFC) or a document from
consortium, university site, etc. suffices. The expert may another standards body, industry consortium, university site, etc.
provide more in depth reviews, but their approval should not be The expert may provide more in depth reviews, but their approval
taken as an endorsement of the key exchange mode. should not be taken as an endorsement of the key exchange mode.
18. Designated Expert Pool 18. Designated Expert Pool
Specification Required [RFC8126] registry requests are registered Specification Required [RFC8126] registry requests are registered
after a three-week review period on the <tls-reg-review@ietf.org> after a three-week review period on the <tls-reg-review@ietf.org>
mailing list, on the advice of one or more designated experts. mailing list, on the advice of one or more designated experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the designated experts may approve registration once they are the designated experts may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
skipping to change at page 17, line 18 skipping to change at page 17, line 18
The change to Specification Required from IETF Review lowers the The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported amount of review provided by the WG for cipher suites and supported
groups. This change reflects reality in that the WG essentially groups. This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported provided no cryptographic review of the cipher suites or supported
groups. This was especially true of national cipher suites. groups. This was especially true of national cipher suites.
Recommended algorithms are regarded as secure for general use at the Recommended algorithms are regarded as secure for general use at the
time of registration; however, cryptographic algorithms and time of registration; however, cryptographic algorithms and
parameters will be broken or weakened over time. It is possible that parameters will be broken or weakened over time. It is possible that
the Recommended status in the registry lags behind the most recent the "Recommended" status in the registry lags behind the most recent
advances in cryptanalysis. Implementers and users need to check that advances in cryptanalysis. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected the cryptographic algorithms listed continue to provide the expected
level of security. level of security.
Designated experts ensure the specification is publicly available. Designated experts ensure the specification is publicly available.
They may provide more in-depth reviews. Their review should not be They may provide more in-depth reviews. Their review should not be
taken as an endorsement of the cipher suite, extension, supported taken as an endorsement of the cipher suite, extension, supported
group, etc. group, etc.
20. IANA Considerations 20. IANA Considerations
 End of changes. 69 change blocks. 
142 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/