ietf-corpus

rfc-4366

Transport Layer Security (TLS) Extensions

S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright
date2006-04 streamIETF areasec wgtls statusPROPOSED STANDARD pages30 canonicalhttps://www.rfc-editor.org/rfc/rfc4366 doi10.17487/RFC4366
This 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]

obsoleted by

obsoletes

updated by

updates

Extracted elements (30)

design-rationale §2.2

The extended ServerHello is sent only in response to an extended ClientHello. This asymmetric design prevents the extended ServerHello from breaking existing TLS clients that do not understand extensions, while still allowing extension negotiation when both parties support it.

tls

interoperability-note §4

The new error alerts (unsupported_extension, unrecognized_name, certificate_unobtainable, bad_certificate_status_response, bad_certificate_hash_value) MUST NOT be sent unless the sending party has received an extended hello message from the peer, to avoid breaking non-extension-aware implementations.

tls

normative-requirement §2.1 MUST

A server that supports the extensions mechanism MUST accept client hello messages in either the original or extended ClientHello format, MUST verify that the message length precisely matches one of these formats, and MUST send a fatal decode_error alert if it does not.

tls, security

normative-requirement §2.3 MUST NOT

An extension type MUST NOT appear in the extended ServerHello unless the same extension type appeared in the corresponding ClientHello. Clients MUST abort the handshake if they receive an unrequested extension type in the ServerHello.

tls, security

normative-requirement §3.6 MUST

Clients requesting an OCSP response and receiving one in a CertificateStatus message MUST check the OCSP response and abort the handshake if the response is not satisfactory.

tls, security, pkix

normative-requirement §3.2 MUST

If a server receives a max_fragment_length value other than the allowed enum values it MUST abort with illegal_parameter. If a client receives a response that differs from the requested length it MUST also abort with illegal_parameter.

tls, security

normative-requirement §3.6 MUST NOT

If a server sends a CertificateStatus message, it MUST have included a status_request extension (with empty extension_data) in the ServerHello. Servers MUST NOT send CertificateStatus unless they received a status_request in the ClientHello.

tls, security

normative-requirement §3.3 MUST

If a SHA-1 hash is present for a URL in CertificateURL, the server MUST verify that the retrieved object's SHA-1 hash matches. On mismatch the server MUST abort with a bad_certificate_hash_value alert. Servers MUST support the http: URL scheme for certificate retrieval.

tls, security, pkix

normative-requirement §5 REQUIRED

New TLS extension type values SHALL be defined only through the IETF Consensus process as specified in RFC 2434 (i.e., only via IESG-approved RFCs), due to subtle security interactions between new and existing features.

tls, security, registry

normative-requirement §3.2 MUST

Once a maximum fragment length other than 2^14 has been successfully negotiated, the client and server MUST immediately begin fragmenting all messages (including handshake messages) so that no fragment exceeds the negotiated length. The negotiated length persists through session resumptions.

tls, security

normative-requirement §3.1 MUST

SNI HostName encoding: ASCII-only labels MUST be separated only by byte 0x2E (dot). Servers matching against non-ASCII names MUST apply IDNA Section 4 conversion treating HostName as a query string with AllowUnassigned set. Literal IPv4 and IPv6 addresses are not permitted in HostName.

tls, security

normative-requirement §3.6 MUST

The OCSP nonce (id-pkix-ocsp-nonce) MUST be a DER-encoded OCTET STRING encapsulated as another OCTET STRING. A zero-length request_extensions value means no extensions, not a zero-length ASN.1 SEQUENCE.

tls, security, pkix

normative-requirement §2.3 MUST NOT

There MUST NOT be more than one extension of the same type in a ClientHello or ServerHello. Extensions may appear in any order.

tls, security

normative-requirement §3 MUST

When session resumption is granted, the server MUST ignore any extensions in the client hello and send a ServerHello containing none of the extension types; functionality negotiated in the original session applies to the resumed session.

tls, security

normative-requirement §3.5 MUST

When truncated HMAC has been negotiated and the cipher suite uses HMAC, both client and server MUST use truncated HMACs: CipherSpec.hash_size is 10 bytes and only the first 10 bytes of HMAC output are transmitted and checked. This does not affect PRF calculation.

tls, security, crypto

privacy-consideration §6.4

The trusted_ca_keys extension reveals which CA root keys a client possesses, which may be regarded as confidential information. Clients should use this extension with care to avoid inadvertently disclosing their trust anchor configuration.

tls, privacy, security

protocol-element §3.6

Certificate Status Request (OCSP stapling): clients send a status_request extension containing a CertificateStatusRequest with CertificateStatusType ocsp(1) and an OCSPStatusRequest carrying a responder_id_list and DER-encoded request_extensions. A zero-length responder_id_list means responders are implicitly known to the server.

tls, security, pkix

protocol-element §3.3

Client Certificate URLs: after negotiating the client_certificate_url extension, clients MAY send a CertificateURL message (handshake type 21) in place of Certificate. It contains a CertChainType (individual_certs or pkipath) and a list of URLAndOptionalHash entries, each with a URL and an optional 20-byte SHA-1 hash.

tls, security, pkix

protocol-element §4

Five new AlertDescription values are defined: unsupported_extension(110) [fatal], certificate_unobtainable(111) [MAY be fatal], unrecognized_name(112) [MAY be fatal], bad_certificate_status_response(113) [fatal], bad_certificate_hash_value(114) [fatal]. These MUST NOT be sent unless the sender received an extended hello from the peer.

tls, security

protocol-element §3.2

Maximum Fragment Length Negotiation: clients send a max_fragment_length extension containing a MaxFragmentLength enum whose allowed values are 2^9(1), 2^10(2), 2^11(3), 2^12(4). Servers echo the same value if they accept. The default TLS maximum plaintext fragment is 2^14 bytes.

tls, security

protocol-element §3.1

Server Name Indication (SNI): clients MAY send a server_name extension containing a ServerNameList with one or more ServerName entries, each specifying a NameType (currently only host_name(0)) and a UTF-8 HostName (1..2^16-1 bytes). Servers respond with an empty server_name extension if they use the information.

tls, security

protocol-element §3.4

Trusted CA Indication: clients MAY include a trusted_ca_keys extension containing a TrustedAuthorities list. Each TrustedAuthority entry identifies a CA root key via one of four IdentifierType values: pre_agreed(0), key_sha1_hash(1), x509_name(2), or cert_sha1_hash(3).

tls, security, pkix

registry §8

IANA maintains the TLS ExtensionType values registry. Initial values: server_name(0), max_fragment_length(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5). New values assigned via IETF Consensus only.

tls, registry

registry §8

IANA registered the MIME type application/pkix-pkipath for DER-encoded PkiPath (SEQUENCE OF Certificate) used in TLS client certificate URL chains. File extension: .pkipath. DER encoding required; base64 SHOULD be used over 7-bit transports.

tls, pkix, registry

security-consideration §6.1 MUST

Implementations MUST ensure that no buffer overflow can occur regardless of the values of length fields in server_name. Internationalized hostnames in SNI may enable hostname spoofing attacks; server certificates SHOULD NOT be issued for internationalized hostnames without spoofing-mitigation procedures.

tls, security

security-consideration §6.3

The client_certificate_url extension turns the TLS server into a URL-fetching client, exposing it to SSRF, DoS (many connections prompting retrieval), and firewall bypass (server may reach internal hosts not publicly accessible). It is RECOMMENDED that this extension be explicitly enabled by an administrator rather than on by default, and that only a minimal set of URL schemes be permitted.

tls, security

wire-format §3.3

CertificateURL wire format: struct { CertChainType type; URLAndOptionalHash url_and_hash_list<1..2^16-1>; }. Each URLAndOptionalHash contains: opaque url<1..2^16-1>, Boolean hash_present, and if true, SHA1Hash[20].

tls, security, pkix

wire-format §2.1

Extended ClientHello adds a client_hello_extension_list field (list of Extension structs, 0..2^16-1 bytes) after the compression_methods field of the standard ClientHello.

tls, security

wire-format §2.2

Extended ServerHello adds a server_hello_extension_list field (0..2^16-1 bytes) after compression_method. Each entry uses the Extension struct: ExtensionType extension_type (2 bytes) followed by opaque extension_data (0..2^16-1 bytes).

tls, security

wire-format §2.3

The Hello Extension format is: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension. ExtensionType is a 2-byte enumeration; extension_data is a variable-length opaque field prefixed by a 2-byte length.

tls, security