Transport Layer Security (TLS) Extensions
obsoleted by
- rfc-4366 — Transport Layer Security (TLS) Extensions
updates
- rfc-2246 — The TLS Protocol Version 1.0
Extracted elements (31)
Backward compatibility is achieved by relying on TLS 1.0's requirement that servers accept extended client hellos even if they do not understand extensions, and by requiring no mandatory server response for any of the defined extensions. Constrained clients may still need to reject servers lacking extension support.
Extensions are designed for constrained wireless environments facing bandwidth, memory, computational, and battery limitations not present in wired environments. The six specific extensions (SNI, max fragment, cert URLs, trusted CA, truncated HMAC, OCSP stapling) directly address these constraints rather than adding general TLS features.
New TLS extensions require IETF Standards Action rather than simple IANA allocation because subtle interactions between new and existing TLS features can significantly reduce overall security — extension fields feed into Finished message hashes, and active attackers can manipulate unauthenticated handshake messages.
When a session is resumed, the server MUST ignore extensions in the client hello and send a server hello with no extensions; the extension functionality negotiated during the original session initiation is applied to the resumed session unchanged.
A server extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello. Clients MUST abort the handshake if they receive an unsolicited extension type in the server hello.
A server supporting extensions MUST accept only client hello messages in either original or extended ClientHello format, MUST verify the message length matches exactly one of those formats, and MUST send a fatal decode_error alert if not. This overrides the TLS 1.0 forward compatibility note.
Clients that request an OCSP response and receive 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 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.
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.
Servers MUST NOT send the CertificateStatus message unless they received a status_request extension in the client hello. If a server sends CertificateStatus, it MUST have included an empty status_request extension in the extended server hello.
Servers that support client_certificate_url MUST support the http: URL scheme for fetching certificate chains, and MAY support other schemes. If a SHA-1 hash is present for a URL, the server MUST verify the hash and MUST abort with bad_certificate_hash_value if it does not match.
The OCSP nonce (id-pkix-ocsp-nonce extension) MUST be a DER-encoded OCTET STRING encapsulated as another OCTET STRING. Implementations based on existing OCSP clients must be checked for conformance.
There MUST NOT be more than one extension of the same type in either the extended client hello or the extended server hello.
When matching HostName against non-ASCII names, servers MUST perform IDNA conversion treating HostName as a query string (AllowUnassigned flag MUST be set). Servers MUST accept any of U+002E, U+3002, U+FF0E, and U+FF61 as label separators. For ASCII-only matching, servers MUST compare case-insensitively.
When truncated HMAC is negotiated and the cipher suite uses HMAC, both client and server MUST use truncated HMACs with CipherSpec.hash_size of 10 bytes — only the first 10 bytes of the HMAC output are transmitted and checked. This does not affect PRF calculations.
Five new TLS alert codes 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 has received an extended hello from the peer.
The extended ClientHello adds a client_hello_extension_list field (Extension list, 0..2^16-1 bytes) to the standard TLS 1.0 ClientHello structure, enabling clients to request extended functionality from servers.
The extended ServerHello adds a server_hello_extension_list field (Extension list, 0..2^16-1 bytes) and MAY be sent in response to an extended ClientHello. The extended server hello is only sent when the client has first sent an extended client hello.
The max_fragment_length extension carries a MaxFragmentLength enum with allowed values 2^9(1), 2^10(2), 2^11(3), 2^12(4). The server must echo the same value to confirm. The negotiated limit applies to TLSPlaintext.length for the full session including resumptions.
The server_name extension carries a ServerNameList containing one or more ServerName entries. Currently only host_name(0) NameType is defined; HostName is a UTF-8 encoded fully qualified DNS hostname (1..2^16-1 bytes), without a trailing dot. Literal IPv4 and IPv6 addresses are not permitted.
Two new handshake message types are introduced: certificate_url(21) for sending client certificate URLs, and certificate_status(22) for conveying certificate status (e.g., OCSP) responses. Both must be included in Finished message hash calculations.
This document creates a TLS extension type registry with values assigned via IETF Standards Action. It also registers the MIME type application/pkix-pkipath for DER-encoded PkiPath (SEQUENCE OF Certificate) certificate chains, with file extension .pkipath.
If a client requires OCSP validation of server certificates, it SHOULD either contact the OCSP server directly or abort the handshake when the server pretends not to support the status_request extension, since a compromised server would likely suppress the extension.
Implementations MUST ensure no buffer overflow occurs from the length fields in server_name. The document does not address security risks from internationalized hostname spoofing; certificates SHOULD NOT be issued for internationalized hostnames without spoofing mitigation procedures.
The client_certificate_url extension makes the server act as a client in URL fetching, exposing it to SSRF-style attacks: an attacker can direct the server to connect to arbitrary URLs, potentially reaching hosts behind firewalls, enabling DoS via many connections, and allowing FTP-bounce or HTTP-proxy-style attacks. It is RECOMMENDED this extension be disabled by default and only minimal URL schemes be enabled.
The trusted_ca_keys extension may reveal which CA root keys a client possesses and should be used with care as this information could be considered confidential.
Each Extension consists of a 2-byte ExtensionType field and an extension_data opaque field (0..2^16-1 bytes). Six extension types are defined: server_name(0), max_fragment_length(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5).
The CertificateStatus handshake message contains a CertificateStatusType and an OCSPResponse field (1..2^24-1 bytes) holding a complete DER-encoded OCSP response. Only one OCSP response may be sent.
The CertificateStatusRequest extension carries a CertificateStatusType (ocsp(1)) and an OCSPStatusRequest containing a responder_id_list (0..2^16-1 bytes of DER-encoded ResponderIDs) and request_extensions (0..2^16-1 bytes, DER-encoded OCSP request extensions).
The CertificateURL message contains a CertChainType (individual_certs(0) or pkipath(1)) and a url_and_hash_list (1..2^16-1 bytes). Each URLAndOptionalHash entry has a url (1..2^16-1 bytes), a Boolean hash_present field, and an optional SHA1Hash (20 bytes) of the certificate or chain.
The trusted_ca_keys extension carries a TrustedAuthorities list of TrustedAuthority entries. Each entry is identified by IdentifierType: pre_agreed(0) (no data), key_sha1_hash(1) (20-byte SHA-1 of public key), x509_name(2) (DER-encoded DistinguishedName, 1..2^16-1 bytes), or cert_sha1_hash(3) (20-byte SHA-1 of DER-encoded certificate).