Transport Layer Security (TLS) Extensions: Extension Definitions
Extracted elements (30)
Earlier versions of this specification permitted multiple names of the same name_type in ServerNameList. In practice, clients only send one name and cannot determine which name the server selected, so multiple names of the same name_type are now prohibited.
The status_request extension allows OCSP certificate status to be delivered within the TLS handshake, saving round trips and conserving bandwidth on constrained networks compared to fetching CRLs separately. The server MAY choose not to send a CertificateStatus even after advertising support, providing flexibility.
All TLS extensions defined in this document are designed to be backwards compatible: clients supporting the extensions can interoperate with servers that do not support them, and vice versa. All extensions are relevant only when a session is initiated, not during abbreviated resumption handshakes.
A server implementing server_name MUST NOT accept a session resumption request if the server_name extension contains a different name than the one used in the original handshake; instead it MUST perform a full handshake. When resuming, the server MUST NOT include a server_name extension in the server hello.
A server MUST NOT send the CertificateStatus message unless it received a status_request extension in the client hello and sent a status_request extension (with empty extension_data) in the server hello.
Any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in 'Finished' messages.
Clients receiving an OCSP response in a CertificateStatus message MUST check the response and abort the handshake with a fatal bad_certificate_status_response(113) alert if the response is not satisfactory.
Each URL in a CertificateURL MUST be an absolute URI reference per RFC 3986. Servers MUST support the 'http' URI scheme and MUST NOT follow HTTP redirects when retrieving certificates.
For the id-pkix-ocsp-nonce OCSP extension, the nonce MUST be a DER-encoded OCTET STRING encapsulated as another OCTET STRING.
If a server is unable to obtain certificates from a CertificateURL and requires them to complete the handshake, it MUST send a fatal certificate_unobtainable(111) alert.
If a server receives a max_fragment_length request for a value other than the allowed values, it MUST abort with 'illegal_parameter'. Similarly, if a client receives a max_fragment_length response that differs from what it requested, it MUST also abort with 'illegal_parameter'.
If an older session is resumed, the server MUST ignore the extensions and send a server hello containing none of the extension types; the functionality negotiated during the original session initiation is applied to the resumed session.
If HMAC truncation is successfully negotiated and the cipher suite uses HMAC, both client and server MUST use truncated HMACs: SecurityParameters.mac_length is 10 bytes and only the first 10 bytes of the HMAC output are transmitted and checked. This does not affect PRF calculations.
If the server understood the ClientHello extension but does not recognize the server name, it SHOULD either abort with a fatal unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name alert because client behavior in response to warning-level alerts is unpredictable.
Literal IPv4 and IPv6 addresses are not permitted in HostName. For all future NameTypes, the associated data structure MUST begin with a 16-bit length field for backward compatibility.
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) to ensure no fragment larger than the negotiated length is sent. The negotiated length applies for the duration of the session including resumptions.
The four new error alerts (certificate_unobtainable, unrecognized_name, bad_certificate_status_response, bad_certificate_hash_value) MUST NOT be sent unless the sending party has received an extended hello message from the communicating party.
The server MUST check that the SHA-1 hash of the retrieved object matches the given hash. If any retrieved object does not have the correct SHA-1 hash, the server MUST abort the handshake with a fatal bad_certificate_hash_value(114) alert.
The ServerNameList MUST NOT contain more than one name of the same name_type.
Four new fatal alert codes are defined: certificate_unobtainable(111) for inaccessible certificate URLs, unrecognized_name(112) for unknown SNI server names, bad_certificate_status_response(113) for unsatisfactory OCSP responses, and bad_certificate_hash_value(114) for SHA-1 hash mismatches on retrieved certificates.
RFC 6066 registers the 'application/pkix-pkipath' MIME type for DER-encoded PkiPath (SEQUENCE OF Certificate), updates TLS Alert Registry values 111-114, HandshakeType Registry values 21-22, and ExtensionType Registry values 0-5 to reference this document.
If a client requires OCSP validation and an attacker's server using a compromised key pretends not to support the status_request extension, the client SHOULD either contact the OCSP server directly or abort the handshake. Use of the OCSP nonce extension may improve security against replay attacks.
If a server hosts multiple virtual domains, the owners of each domain must ensure that hosting together satisfies their security needs. Implementations MUST ensure buffer overflows cannot occur on arbitrary values of the length fields in server_name.
The CA root keys indicated via trusted_ca_keys could be regarded as confidential information. The extension should be used with care to avoid leaking which CAs a constrained client trusts.
The client_certificate_url extension causes the TLS server to act as a client in another protocol when fetching certificates, making it subject to SSRF-like attacks: an attacker may prompt the server to connect to arbitrary URLs, potentially targeting internal hosts behind firewalls or launching DoS attacks. It is RECOMMENDED that this extension be explicitly enabled by an administrator and that only a minimal set of URI schemes be allowed.
The CertificateURL message contains a CertChainType (individual_certs(0) or pkipath(1)) and a URLAndHash list. Each URLAndHash entry contains a variable-length URL (opaque, 1..2^16-1), a padding byte (MUST be 0x01), and a 20-byte SHA1Hash of the certificate or chain.
The max_fragment_length extension_data contains a MaxFragmentLength enum (1 byte) whose allowed values are 2^9(1), 2^10(2), 2^11(3), and 2^12(4), representing the desired maximum plaintext fragment size in bytes.
The server_name extension_data field contains a ServerNameList: a list of ServerName structs, each with a NameType (1 byte) and a variable-length HostName (opaque, 1..2^16-1 bytes). Currently only host_name(0) is defined; HostName is an ASCII-encoded DNS hostname without trailing dot.
The status_request extension contains a CertificateStatusRequest with a CertificateStatusType (ocsp(1)) and an OCSPStatusRequest containing a list of ResponderIDs (opaque, 1..2^16-1 each) and DER-encoded Extensions (opaque, 0..2^16-1). The CertificateStatus response contains a status_type and an OCSPResponse (opaque, 1..2^24-1).
The trusted_ca_keys extension contains a TrustedAuthorities structure: a list of TrustedAuthority entries, each identified by an IdentifierType (pre_agreed(0), key_sha1_hash(1), x509_name(2), or cert_sha1_hash(3)) with the corresponding identifier value.