IANA Registry Updates for TLS and DTLS
updated by
- rfc-9847 — IANA Registry Updates for TLS and DTLS
updates
- rfc-3749 — Transport Layer Security Protocol Compression Methods
- rfc-4680 — TLS Handshake Message for Supplemental Data
- rfc-5077 — Transport Layer Security (TLS) Session Resumption without Server-Side State
- rfc-5246 — The Transport Layer Security (TLS) Protocol Version 1.2
- rfc-5705 — Keying Material Exporters for Transport Layer Security (TLS)
- rfc-5878 — Transport Layer Security (TLS) Authorization Extensions
- rfc-6520 — Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
- rfc-7301 — Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
Extracted elements (20)
A cryptographic-algorithms warning was added to the TLS Cipher Suites and Supported Groups registries because some customers use these registries as implementation checklists and some implementers blindly implement all listed values, a behavior the document characterizes as misguided.
A 'Recommended' column was added to TLS registries to indicate parameters generally recommended for implementations, decoupling formal registration (which now requires only Specification Required) from a guidance signal about which parameters the WG endorses for broad use.
The registry policy for TLS extensions and cipher suites was loosened from IETF Review to Specification Required because the WG essentially provided no cryptographic review of cipher suites or supported groups anyway, especially for national cipher suites. The change reflects operational reality rather than a reduction in intended rigor.
TLS 1.3 cipher suites occupy the same code space as prior TLS versions but are defined differently, specifying only symmetric ciphers and hash function. TLS 1.3 cipher suites cannot be used with TLS 1.2, and TLS 1.2 and lower cipher suites cannot be used with TLS 1.3.
Adding a 'Recommended' value of 'Y' to any TLS registry requires Standards Action. IESG Approval is REQUIRED for a Y→N transition (downgrading a previously recommended parameter).
For TLS Exporter Labels, IANA MUST verify that no label is a prefix of any other label. The designated expert also verifies that labels consist of printable ASCII characters beginning with 'EXPORTER'.
IANA MUST only accept registry updates from the designated experts and SHOULD direct all requests for registration to the review mailing list (tls-reg-review@ietf.org).
Registration requests undetermined for longer than 21 days can be escalated to the IESG (iesg@ietf.org) for resolution. Designated experts in conflict of interest SHOULD defer to the judgment of other experts.
Specification Required registry requests undergo a three-week review period on the tls-reg-review@ietf.org mailing list. Registration requests SHOULD use an appropriate subject line. Denials SHOULD include an explanation and suggestions for how to make the request successful.
A 'Recommended' column was added to the TLS Exporter Labels registry, marking Standards Track RFC labels as 'Y'. A note clarifies that TLS 1.3 replaced the PRF with HKDF, requiring a new construction while keeping the same exporter interface.
Four registries were renamed to prepend 'TLS' for consistency: Application-Layer Protocol Negotiation (ALPN) Protocol IDs, ExtensionType Values, Heartbeat Message Types, and Heartbeat Modes.
The missing alert value 120 'no_application_protocol' (from RFC 7301) was added to the TLS Alerts registry with Recommended='Y'. This entry had been omitted from the original IANA instructions in RFC 7301.
The TLS Certificate Types registry policy was changed from IETF Consensus to Specification Required for values 0-223, with 224-255 reserved for Private Use. A 'Recommended' column was added with X.509 and Raw Public Key marked as 'Y'.
The TLS Cipher Suites registry policy was changed from IETF Consensus to Specification Required for values with first byte 0-254, with first byte 255 reserved for Private Use. A 'Recommended' column was added marking specific ECDHE/DHE cipher suites with AES-GCM, AES-CCM, and ChaCha20-Poly1305 as 'Y'.
The TLS ClientCertificateType Identifiers registry policy was changed from IETF Consensus to: Standards Action for 0-63, Specification Required for 64-223, and Private Use for 224-255. A note was added that values are only applicable to (D)TLS versions prior to 1.3.
The TLS Compression Method Identifiers, TLS HashAlgorithm, and TLS SignatureAlgorithm registries were annotated as orphaned: their values apply only to (D)TLS versions prior to 1.3. TLS 1.3 values for signature algorithms are registered in the TLS SignatureScheme registry instead.
The TLS ExtensionType Values registry policy was changed from IETF Review to Specification Required for values 0-254, with values 255 (first byte) reserved for Private Use. A 'Recommended' column was added, and a 'TLS 1.3' column listing which messages each extension may appear in was also added.
Two registries were updated from 'IETF Consensus' to 'IETF Review' to align with updated RFC 8126 terminology: TLS Authorization Data Formats (RFC 4680) and TLS Supplemental Data Formats (RFC 5878).
Changing the registration policy from IETF Review to Specification Required lowers the amount of review provided for cipher suites and supported groups. Designated experts ensure specifications are publicly available but their approval is not an endorsement of cryptographic strength.
Recommended algorithms are regarded as secure at time of registration, but cryptographic algorithms and parameters will be broken or weakened over time. The 'Recommended' status in the registry may lag behind current cryptanalysis; implementers must independently verify that listed algorithms still provide expected security.