Transport Layer Security Protocol Compression Methods
updated by
Extracted elements (17)
DEFLATE compression in TLS is stateful (compressor maintains state across records) rather than stateless, because stateless compression provides little known benefit within TLS's reliable, sequenced delivery environment while stateful compression achieves higher ratios on streams.
Session resumption requires clearing compression history (but retaining the algorithm) to avoid operational complexity for load balancers that would otherwise need to maintain additional state about the compression context.
TLS originally defined only CompressionMethod.null, limiting interoperability for implementations wanting compression. This document adds DEFLATE (value 1) as a standard method to enable interoperable compressed TLS implementations.
A compression method that exceeds the expansion limits described in section 6.2.2 of RFC 2246 (1,024 bytes content length increase, 2^14 bytes total) MUST NOT be used with TLS.
All data submitted for DEFLATE compression MUST be included in the compressed output with no data retained for a later payload, ensuring each compressed packet can be fully decompressed (flushing requirement).
Compression history information MAY be maintained and exploited if supported by the compression method, since TLS and lower-layer protocols provide reliable, sequenced packet delivery.
It is RECOMMENDED that other compression methods standardized in the future be stateful, as there is little known benefit in using stateless compression within TLS.
The receiving DEFLATE decompressor MUST automatically adjust to the compression parameters selected by the sender.
Use of TLS compression SHOULD take into account that the length of compressed data may leak more information than the length of the original uncompressed data.
When resuming a TLS session, the compression algorithm MUST be retained.
When resuming a TLS session, the compression state/history MUST be cleared.
DEFLATE compression (RFC 1951) is defined as a stateful TLS compression method with identifier value 1. The sender selects compression parameters; the receiver must adapt automatically and all input data must appear in the compressed output with mandatory flushing.
The CompressionMethod enumeration is updated to define three zones: 0-63 for IETF Standards Track, 64-223 for non-Standards Track, and 224-255 for private use. DEFLATE is assigned identifier value 1.
IANA maintains a registry of TLS compression method identifiers. Values 0-63 are assigned via Standards Action, 64-223 via Specification Required, and 224-255 are reserved for Private Use.
Combining compression with encryption can reveal information through length: compressed ciphertext lengths may allow adversaries to infer properties of the plaintext, particularly with stream ciphers or CBC with fixed padding. This is an inherent risk of TLS compression.
Compression algorithms are mathematically complex and prone to implementation errors such as buffer overruns, which introduce security risks in languages and operating systems without buffer overrun protections.
Compression algorithms can expand rather than compress input, enabling construction of rogue data that expands to enormous size. RFC 2246 mitigates this by requiring lossless compression, limiting content length increase to 1,024 bytes, and capping total content at 2^14 bytes.