Transport Layer Security (TLS) Cached Information Extension
Extracted elements (22)
The extension was designed for IoT and constrained environments (IEEE 802.15.4, Bluetooth Low Energy, low-power WANs) where low bandwidth and lossy radio links make transmitting large certificate chains in every handshake prohibitively expensive.
The fingerprint is intentionally not a security mechanism; the security of the handshake depends on the private key. The fingerprint's role is only to help the server select the correct cached object (e.g., the right certificate) and to prevent accidental selection of the wrong one.
The specification recommends reusing hash algorithms already present in TLS ciphersuites to avoid additional code complexity while keeping collision probability low, which is why SHA-256 was chosen as the baseline.
In hosting environments where a client may have cached multiple certificates for one server, the specification RECOMMENDS that the client use the Server Name Indication (SNI) extension (RFC 6066) to allow the server to select the correct cached object.
The cached_info extension is applicable to DTLS as well as TLS; the description in this document covers both protocols equally.
This extension is compatible with RFC 7250 raw public keys. When a raw public key is negotiated, the server omits the SubjectPublicKeyInfo-bearing ASN.1 structure rather than the full certificate chain.
Clients MUST ensure they only cache information from legitimate sources. Information MUST only be cached after the successful completion of a TLS exchange to prevent cache poisoning by an attacker.
For each cached info type indicated in the ServerHello, the server MUST alter transmission of the respective payload. The server MUST only include CachedObjects of types also indicated by the client in the ClientHello.
For the 'cert' type, the client MUST include the fingerprint of the full Certificate message in the hash_value field. For 'cert_req', the client MUST include the fingerprint of the CertificateRequest message.
If a client includes the 'cached_info' extension in the ClientHello, the extension_data MUST contain the CachedInformation structure and MUST include one or more CachedObject attributes.
If the server detects a mismatch between the client's cached fingerprint and its own data, it MUST send the full information and MUST NOT list the respective type in the 'cached_info' extension in the ServerHello.
The fingerprint MUST be computed as the SHA-256 hash of the full handshake message (not including record-layer type/length). New hash algorithms added for future cached info types MUST NOT have collision resistance worse than SHA-256.
The 'cached_info' extension (type 25) is defined for use in ClientHello and ServerHello messages, allowing a client to inform the server of previously cached TLS handshake objects by type and fingerprint.
Two CachedInformationType values are defined: 'cert' (1) for caching the server Certificate message, and 'cert_req' (2) for caching the CertificateRequest message. Values 0 and 224–255 are reserved.
IANA added cached_info(25) to the existing TLS 'ExtensionType Values' registry defined in RFC 5246.
IANA established a new 'TLS CachedInformationType Values' registry with values: 0 (Reserved), 1 (cert), 2 (cert_req), 224–255 (Private Use). Registration policy: 0–63 Standards Action; 64–223 Specification Required.
If an attacker injects a forged fingerprint, two outcomes arise: (1) the fingerprint maps to no cached state and the server falls back to a full exchange, or (2) the fingerprint maps to data the client has not cached, causing a signature verification failure that aborts the handshake.
Omitted handshake payloads (certificate, CertificateRequest) are not included in the Finished message transcript, but their fingerprints are exchanged in the initial messages and thus are covered by the Finished MAC.
Sending a fingerprint of cached information in the unencrypted ClientHello and ServerHello allows a passive observer or active attacker to correlate independent TLS sessions, potentially undermining unlinkability goals depending on the sensitivity of the cached object type.
The CachedObject structure contains a CachedInformationType field and, on the client side, an opaque hash_value field of 1–255 bytes. On the server side the body contains only the type. Multiple CachedObjects are grouped in a CachedInformation struct with a 2-byte length prefix (1..2^16-1 bytes).
When the 'cert' cached info type is negotiated, the server sends a modified Certificate message containing only an opaque hash_value field (1..255 bytes) instead of the full certificate chain payload defined in RFC 5246.
When the 'cert_req' cached info type is negotiated, the server sends a modified CertificateRequest message containing only an opaque hash_value field (1..255 bytes) rather than the full CertificateRequest structure.