Transport Layer Security (TLS) Extensions
obsoleted by
- rfc-5246 — The Transport Layer Security (TLS) Protocol Version 1.2
- rfc-6066 — Transport Layer Security (TLS) Extensions: Extension Definitions
obsoletes
- rfc-3546 — Transport Layer Security (TLS) Extensions
updated by
- rfc-5746 — Transport Layer Security (TLS) Renegotiation Indication Extension
updates
- rfc-4346 — The Transport Layer Security (TLS) Protocol Version 1.1
Extracted elements (30)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
There MUST NOT be more than one extension of the same type in a ClientHello or ServerHello. Extensions may appear in any order.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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].
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.
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).
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.