Transport Layer Security (TLS) Certificate CompressionCloudflare, Inc.alessandro@cloudflare.comGooglevasilvv@google.com
Security
TLSIn Transport Layer Security (TLS) handshakes, certificate chains often take up
the majority of the bytes transmitted.This document describes how certificate chains can be compressed to reduce the
amount of data transmitted and avoid some round trips.In order to reduce latency and improve performance it can be useful to reduce
the amount of data exchanged during a Transport Layer Security (TLS) handshake. describes a mechanism that allows a client and a server to avoid
transmitting certificates already shared in an earlier handshake, but it
doesn’t help when the client connects to a server for the first time and
doesn’t already have knowledge of the server’s certificate chain.This document describes a mechanism that would allow server certificates to be
compressed during full handshakes.The words “MUST”, “MUST NOT”, “SHALL”, “SHOULD”, and “MAY” are used in this
document. It’s not shouting; when they are capitalized, they have the special
meaning defined in .This document defines a new extension type (compress_server_certificates(TBD)),
which is used by the client and the server to negotiate the use of compression
for the server certificate chain, as well as the choice of the compression
algorithm.By sending the compress_server_certificates message, the client indicates to the
server the certificate compression algorithms it supports. The “extension_data”
field of this extension in the ClientHello SHALL contain a
CertificateCompressionAlgorithms value:If the server supports any of the algorithms offered in the ClientHello, it MAY
respond with an extension indicating which compression algorithm it chose. In
that case, the extension_data SHALL be a CertificateCompressionAlgorithm value
corresponding to the chosen algorithm. If the server has chosen to not use any
compression, it MUST NOT send the compress_server_certificates extension.If the server picks a compression algorithm and sends it in the ServerHello, the
format of the Certificate message is altered as follows:
The length of the Certificate message once it is uncompressed. If after
decompression the specified length does not match the actual length, the
client MUST abort the connection with the “bad_certificate” alert.
The compressed body of the Certificate message, in the same format as the
server would normally express it. The compression algorithm defines how the
bytes in the compressed_certificate_message are converted into the
Certificate message.If the specified compression algorithm is zlib, then the Certificate message
MUST be compressed with the ZLIB compression algorithm, as defined in .
If the specified compression algorithm is brotli, the Certificate message MUST
be compressed with the Brotli compression algorithm as defined in .If the client cannot decompress the received Certificate message from the
server, it MUST tear down the connection with the “bad_certificate” alert.The extension only affects the Certificate message from the server. It does not
change the format of the Certificate message sent by the client.If the format of the message is altered using the server_certificate_type
extension , the resulting altered message is compressed instead.If the server chooses to use the cached_info extension to replace
the Certificate message with a hash, it MUST NOT send the
compress_server_certificates extension.After decompression, the Certificate message MUST be processed as if it were
encoded without being compressed. This way, the parsing and the verification
have the same security properties as they would have in TLS normally.Since certificate chains are typically presented on a per-server name basis, the
attacker does not have control over any individual fragments in the Certificate
message, meaning that they cannot leak information about the certificate by
modifying the plaintext.The implementations SHOULD bound the memory usage when decompressing the
Certificate message.The implementations MUST limit the size of the resulting decompressed chain to
the specified uncompressed length, and they MUST abort the connection if the
size exceeds that limit. TLS framing imposes 16777216 byte limit on the
certificate message size, and the implementations MAY impose a limit that is
lower than that; in both cases, they MUST apply the same limit as if no
compression were used.Create an entry, compress_server_certificates(TBD), in the existing registry for
ExtensionType (defined in ).This document establishes a registry of compression algorithms supported for
compressing the Certificate message, titled “Certificate Compression Algorithm
IDs”, under the existing “Transport Layer Security (TLS) Extensions” heading.The entries in the registry are:Algorithm NumberDescription0zlib1brotli224 to 255Reserved for Private UseThe values in this registry shall be allocated under “IETF Review” policy for
values strictly smaller than 64, and under “Specification Required” policy
otherwise (see for the definition of relevant policies).ZLIB Compressed Data Format Specification version 3.3This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Transport Layer Security (TLS) ExtensionsThis 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]Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.Brotli Compressed Data FormatThis specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.Transport Layer Security (TLS) Cached Information ExtensionTransport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.