RFC 3749

RFC 3749: Transport Layer Security Protocol Compression Methods 💖

Okay bestie, here's the header tea ☕ This RFC was written by S. Hollenbeck at VeriSign, Inc., it's a Standards Track doc, and it's dated May 2004. The header doesn't list anything it obsoletes or updates, so it's just vibing on its own 🦋

---

Status of This Memo 🌸

Okay so this is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) doc. Distribution of this memo is unlimited, so share away 💅

Copyright Notice ©

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🎀

So TLS (RFC 2246) has this feature where you negotiate a lossless data compression method during the TLS Handshake Protocol, then apply that algorithm in the TLS Record Protocol 🧚 TLS only ships with one standard method, and it says the data going over the record protocol won't get compressed at all. This doc adds an extra compression method built on a lossless algorithm for TLS, and it also explains how to specify more TLS compression methods later 💜

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Compression Methods  . . . . . . . . . . . . . . . . . . . . .  2
    2.1.  DEFLATE Compression. . . . . . . . . . . . . . . . . . .  3
3.  Compression History and Packet Processing  . . . . . . . . . .  4
4.  Internationalization Considerations  . . . . . . . . . . . . .  4
5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
    8.1.  Normative References . . . . . . . . . . . . . . . . . .  6
    8.2.  Informative References . . . . . . . . . . . . . . . . .  6
    Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
    Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8

1. Introduction ✨

TLS (RFC 2246, [2]) lets you negotiate a lossless data compression method as part of the TLS Handshake Protocol, and then apply that algorithm as part of the TLS Record Protocol. TLS defines one standard compression method, CompressionMethod.null, which says data sent over the record protocol won't be compressed. Having that single method helps TLS implementations play nicely together, but without more standard methods, implementers had a hard time building interoperable versions that actually compress stuff 😭

TLS is everywhere for securing client-server connections on the World Wide Web 🌍 A lot of those connections are short-lived and only move small amounts of data, but TLS also gets used where connections stick around and the data can reach thousands or millions of octets. XML [4], for example, is blowing up as a data representation method on the Internet, and XML is super verbose 🙈 Compression inside TLS helps cut the bandwidth and latency needed to move big piles of data, while keeping the security services TLS provides 🔥

This doc describes an extra compression method using a lossless algorithm for TLS. Standardizing the compressed data formats and the compression algorithms themselves is out of scope here 🙅

Quick heads up on the key words 📣 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

2. Compression Methods 🌈

TLS [2] has the following compression method structure in sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:

enum { null(0), (255) } CompressionMethod;

This allows for later specification of up to 256 different compression methods. The definition gets updated to split the range of allowable values into three zones:

1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols.
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are set aside for assignment to non-Standards Track methods.
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use.

For more on how the IANA handles allocating compression method identifiers, check Section 5 💅

The definition also gets updated to include an identifier for the DEFLATE compression method:

enum { null(0), DEFLATE(1), (255) } CompressionMethod;

As described in section 6 of RFC 2246 [2], TLS is a stateful protocol. Compression methods used with TLS can be either stateful (the compressor keeps its state through all compressed records) or stateless (the compressor compresses each record independently). There seems to be little known benefit in using a stateless compression method within TLS, though 🤔

The DEFLATE compression method in this document is stateful. It is RECOMMENDED that other compression methods that might be standardized in the future be stateful as well ✨

Compression algorithms can occasionally expand, rather than compress, input data. A compression method that exceeds the expansion limits described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS. Absolutely not, bestie 🙅‍♀️

2.1. DEFLATE Compression 🧃

The DEFLATE compression method and encoding format is described in RFC 1951 [5]. You can see DEFLATE in action in IETF protocols in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8].

DEFLATE lets the sending compressor pick from several options to get different compression ratios, processing speeds, and memory requirements. The receiving decompressor MUST automatically adjust to the parameters the sender picked 🫶 All data submitted for compression MUST be included in the compressed output, with no data held back for a later output payload. Flushing makes sure each compressed packet payload can be decompressed completely 💖

3. Compression History and Packet Processing 🦋

Some compression methods can maintain state/history information while compressing and decompressing packet payloads. Compression history gets you a higher compression ratio on a stream compared to per-packet compression, but keeping history across packets means one packet might hold data needed to fully decompress data in a different packet. That's giving "history maintenance requires both a reliable link and sequenced packet delivery" energy 🧠 Since TLS and the lower-layer protocols already provide reliable, sequenced packet delivery, compression history information MAY be maintained and exploited if the compression method supports it ✨

As described in section 7 of RFC 2246 [2], TLS lets multiple connections be instantiated using the same session through the resumption feature of the TLS Handshake Protocol. Session resumption has operational implications when multiple compression methods are available within the session. For example, load balancers will need to maintain extra state information if the compression state isn't cleared when a session is resumed 😩 So the following restrictions MUST be observed when resuming a session:

1. The compression algorithm MUST be retained when resuming a session.
2. The compression state/history MUST be cleared when resuming a session.

4. Internationalization Considerations 🌏

The compression method identifiers in this document are machine-readable numbers. Because of that, issues of human internationalization and localization aren't introduced 🔢

5. IANA Considerations 📋

Section 2 of this document describes a registry of compression method identifiers that the IANA maintains, including an identifier for the DEFLATE compression method. Identifier values from the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action [3]. Values from the range 64-223 (decimal) inclusive are assigned via RFC 2434 Specification Required [3]. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use [3].

6. Security Considerations 💀

Okay, this section is serious, so let's get into it 🔐

This document doesn't introduce anything that changes the threat model TLS already addresses. The security considerations described throughout RFC 2246 [2] apply here as well.

However, combining compression with encryption can sometimes reveal information that wouldn't have been revealed without compression. Data that's the same length before compression might be a different length after compression, so adversaries who observe the length of the compressed data might be able to derive information about the corresponding uncompressed data. Some symmetric encryption ciphersuites don't hide the length of symmetrically encrypted data at all. Others hide it to some extent, but still don't hide it fully. For example, ciphersuites that use stream cipher encryption without padding don't hide length at all, and ciphersuites that use Cipher Block Chaining (CBC) encryption with padding provide some length hiding, depending on how the amount of padding is chosen. 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 🙀

Compression algorithms tend to be mathematically complex and prone to implementation errors. An implementation error that can produce a buffer overrun is a real security risk for programming languages and operating systems that don't provide buffer overrun protections. Careful consideration should thus be given to protections against implementation errors that introduce security risks 🚨

As described in Section 2, compression algorithms can occasionally expand, rather than compress, input data. That feature makes it possible to construct rogue data that expands to some enormous size when compressed or decompressed. RFC 2246 describes several methods to ameliorate this kind of attack. First, compression has to be lossless. Second, a limit (1,024 bytes) is placed on the amount of allowable compression content length increase. Finally, a limit (2^14 bytes) is placed on the total content length. See section 6.2.2 of RFC 2246 [2] for complete details 🛡️

7. Acknowledgements 🫶

The concepts in this document were originally discussed on the IETF TLS working group mailing list in December, 2000. The author acknowledges the contributions to that discussion provided by Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later suggestions that were incorporated into this document came from Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the IESG 👑

8. References 📚

8.1. Normative References ✨

okay so these are the must-reads 🤓 the stuff the spec leans on, so you need it to actually follow along 📚

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
• [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8.2. Informative References 🧚

these ones are extra reading, nice to have but not required to get the main idea 💜

• [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
• [5] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
• [6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
• [7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
• [8] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

---

Author's Address 💌

here's who wrote it, the girl behind the keyboard 🎀

Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166-6503
US

EMail: shollenbeck@verisign.com

Full Copyright Statement ⭐

so, the legal bit, but make it cute 💅 the copyright belongs to The Internet Society (2004), and the whole doc is covered by BCP 78. outside of that, the authors keep all their rights 🫶

the doc and everything in it is handed over "AS IS", and the people involved (THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE) are DISCLAIMING ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 😭

Intellectual Property 🔥

the IETF is staying neutral here 🤷‍♀️ it takes no position on whether any IPR (intellectual property rights) might cover the tech in this doc, or whether a license would even be available. it also hasn't done any independent digging to find out what rights exist 👀 if you want the rules on rights in RFC docs, check BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, plus any license assurances, or results from trying to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️

and the IETF is totally inviting anyone to speak up about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💖

Acknowledgement 🌈

big thank you moment 🥹 funding for the RFC Editor function is currently provided by the Internet Society ✨