ietf-corpus

rfc-8447

IANA Registry Updates for TLS and DTLS

J. Salowey, S. Turner
date2018-08 streamIETF areasec wgtls statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc8447 doi10.17487/RFC8447 errataview
This document describes a number of changes to TLS and DTLS 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 TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

updated by

updates

Extracted elements (20)

design-rationale §8

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.

tls, registry, security

design-rationale §5

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.

tls, registry

design-rationale §18

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, registry, security

interoperability-note §8

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.

tls

normative-requirement §5 REQUIRED

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).

tls, registry, security

normative-requirement §12 MUST

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'.

tls, registry

normative-requirement §17 MUST

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).

tls, registry, process

normative-requirement §17 SHOULD

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.

tls, registry, process

normative-requirement §17 SHOULD

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.

tls, registry, process

registry §12

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.

tls, registry, crypto

registry §3

Four registries were renamed to prepend 'TLS' for consistency: Application-Layer Protocol Negotiation (ALPN) Protocol IDs, ExtensionType Values, Heartbeat Message Types, and Heartbeat Modes.

tls, registry

registry §13

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.

tls, registry

registry §14

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'.

tls, registry, pkix

registry §8

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'.

tls, registry, crypto

registry §10

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.

tls, registry

registry §15

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.

tls, registry

registry §7

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.

tls, registry

registry §4

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).

tls, registry

security-consideration §18

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.

tls, security, crypto

security-consideration §18

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.

tls, security, crypto