idnits 2.17.1 draft-ietf-tls-compression-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to directly say this. It does mention RFC2246 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 2004) is 7404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hollenbeck 2 Internet-Draft VeriSign, Inc. 3 Updates: 2246 (if approved) January 16, 2004 4 Expires: July 16, 2004 6 Transport Layer Security Protocol Compression Methods 7 draft-ietf-tls-compression-07.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on July 16, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The Transport Layer Security (TLS) protocol (RFC 2246) includes 38 features to negotiate selection of a lossless data compression method 39 as part of the TLS Handshake Protocol and to then apply the algorithm 40 associated with the selected method as part of the TLS Record 41 Protocol. TLS defines one standard compression method which 42 specifies that data exchanged via the record protocol will not be 43 compressed. This document describes an additional compression method 44 associated with a lossless data compression algorithm for use with 45 TLS, and it describes a method for the specification of additional 46 TLS compression methods. 48 Conventions Used In This Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 3 58 2.1 DEFLATE Compression . . . . . . . . . . . . . . . . . . . . . 4 59 3. Compression History and Packet Processing . . . . . . . . . . 4 60 4. Internationalization Considerations . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 Normative References . . . . . . . . . . . . . . . . . . . . . 6 65 Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . 8 69 1. Introduction 71 The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes 72 features to negotiate selection of a lossless data compression method 73 as part of the TLS Handshake Protocol and to then apply the algorithm 74 associated with the selected method as part of the TLS Record 75 Protocol. TLS defines one standard compression method, 76 CompressionMethod.null, which specifies that data exchanged via the 77 record protocol will not be compressed. While this single 78 compression method helps ensure that TLS implementations are 79 interoperable, the lack of additional standard compression methods 80 has limited the ability of implementers to develop interoperable 81 implementations that include data compression. 83 TLS is used extensively to secure client-server connections on the 84 World Wide Web. While these connections can often be characterized 85 as short-lived and exchanging relatively small amounts of data, TLS 86 is also being used in environments where connections can be 87 long-lived and the amount of data exchanged can extend into thousands 88 or millions of octets. XML [4], for example, is increasingly being 89 used as a data representation method on the Internet, and XML tends 90 to be verbose. Compression within TLS is one way to help reduce the 91 bandwidth and latency requirements associated with exchanging large 92 amounts of data while preserving the security services provided by 93 TLS. 95 This document describes an additional compression method associated 96 with a lossless data compression algorithm for use with TLS. 97 Standardization of the compressed data formats and compression 98 algorithms associated with this compression method is beyond the 99 scope of this document. 101 2. Compression Methods 103 TLS [2] includes the following compression method structure in 104 sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6: 106 enum { null(0), (255) } CompressionMethod; 108 which allows for later specification of up to 256 different 109 compression methods. This definition is updated to segregate the 110 range of allowable values into three zones: 112 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are 113 reserved for IETF Standards Track protocols. 115 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) 116 inclusive are reserved for assignment for non-Standards Track 117 methods. 119 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) 120 inclusive are reserved for private use. 122 Additional information describing the role of the IANA in the 123 allocation of compression method identifiers is described in Section 124 5. 126 In addition, this definition is updated to include assignment of an 127 identifier for the DEFLATE compression method: 129 enum { null(0), DEFLATE(1), (255) } CompressionMethod; 131 As described in section 6 of RFC 2246 [2], TLS is a stateful 132 protocol. Compression methods used with TLS can be either stateful 133 (the compressor maintains its state through all compressed records) 134 or stateless (the compressor compresses each record independently), 135 but there seems to be little known benefit in using a stateless 136 compression method within TLS. 138 The DEFLATE compression method described in this document is 139 stateful. It is RECOMMENDED that other compression methods that might 140 be standardized in the future be stateful as well. 142 Compression algorithms can occasionally expand, rather than compress, 143 input data. A compression method that exceeds the expansion limits 144 described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS. 146 2.1 DEFLATE Compression 148 The DEFLATE compression method and encoding format is described in 149 RFC 1951 [5]. Examples of DEFLATE use in IETF protocols can be found 150 in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8]. 152 DEFLATE allows the sending compressor to select from among several 153 options to provide varying compression ratios, processing speeds, and 154 memory requirements. The receiving decompressor MUST automatically 155 adjust to the parameters selected by the sender. All data that was 156 submitted for compression MUST be included in the compressed output, 157 with no data retained to be included in a later output payload. 158 Flushing ensures that each compressed packet payload can be 159 decompressed completely. 161 3. Compression History and Packet Processing 163 Some compression methods have the ability to maintain state/history 164 information when compressing and decompressing packet payloads. The 165 compression history allows a higher compression ratio to be achieved 166 on a stream as compared to per-packet compression, but maintaining a 167 history across packets implies that a packet might contain data 168 needed to completely decompress data contained in a different packet. 169 History maintenance thus requires both a reliable link and sequenced 170 packet delivery. Since TLS and lower-layer protocols provide 171 reliable, sequenced packet delivery, compression history information 172 MAY be maintained and exploited if supported by the compression 173 method. 175 As described in section 7 of RFC 2246 [2], TLS allows multiple 176 connections to be instantiated using the same session through the 177 resumption feature of the TLS Handshake Protocol. Session resumption 178 has operational implications when multiple compression methods are 179 available for use within the session. For example, load balancers 180 will need to maintain additional state information if the compression 181 state is not cleared when a session is resumed. As a result, the 182 following restrictions MUST be observed when resuming a session: 184 1. The compression algorithm MUST be retained when resuming a 185 session. 187 2. The compression state/history MUST be cleared when resuming a 188 session. 190 4. Internationalization Considerations 192 The compression method identifiers specified in this document are 193 machine-readable numbers. As such, issues of human 194 internationalization and localization are not introduced. 196 5. IANA Considerations 198 Section 2 of this document describes a registry of compression method 199 identifiers to be maintained by the IANA, including assignment of an 200 identifier for the DEFLATE compression method. Identifier values 201 from the range 0-63 (decimal) inclusive are assigned via RFC 2434 202 Standards Action [3]. Values from the range 64-223 (decimal) 203 inclusive are assigned via RFC 2434 Specification Required [3]. 204 Identifier values from 224-255 (decimal) inclusive are reserved for 205 RFC 2434 Private Use [3]. 207 6. Security Considerations 209 This document does not introduce any topics that alter the threat 210 model addressed by TLS. The security considerations described 211 throughout RFC 2246 [2] apply here as well. 213 However, combining compression with encryption can sometimes reveal 214 information that would not have been revealed without compression: 215 data that is the same length before compression might be a different 216 length after compression, so adversaries that observe the length of 217 the compressed data might be able to derive information about the 218 corresponding uncompressed data. Some symmetric encryption 219 ciphersuites do not hide the length of symmetrically encrypted data 220 at all. Others hide it to some extent, but still don't hide it 221 fully. For example, ciphersuites that use stream cipher encryption 222 without padding do not hide length at all; ciphersuites that use 223 Cipher Block Chaining (CBC) encryption with padding provide some 224 length hiding, depending on how the amount of padding is chosen. Use 225 of TLS compression SHOULD take into account that the length of 226 compressed data may leak more information than the length of the 227 original uncompressed data. 229 Compression algorithms tend to be mathematically complex and prone to 230 implementation errors. An implementation error that can produce a 231 buffer overrun introduces a potential security risk for programming 232 languages and operating systems that do not provide buffer overrun 233 protections. Careful consideration should thus be given to 234 protections against implementation errors that introduce security 235 risks. 237 As described in Section 2, compression algorithms can occasionally 238 expand, rather than compress, input data. This feature introduces 239 the ability to construct rogue data that expands to some enormous 240 size when compressed or decompressed. RFC 2246 describes several 241 methods to ameliorate this kind of attack. First, compression has to 242 be lossless. Second, a limit (1,024 bytes) is placed on the amount of 243 allowable compression content length increase. Finally, a limit 244 (2^14 bytes) is placed on the total content length. See section 245 6.2.2 of RFC 2246 [2] for complete details. 247 7. Acknowledgements 249 The concepts described in this document were originally discussed on 250 the IETF TLS working group mailing list in December, 2000. The 251 author acknowledges the contributions to that discussion provided by 252 Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later 253 suggestions that have been incorporated into this document were 254 provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos 255 Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the 256 IESG. 258 Normative References 260 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 261 Levels", BCP 14, RFC 2119, March 1997. 263 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 264 2246, January 1999. 266 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 267 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 269 Informative References 271 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 272 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 273 October 2000, . 275 [5] Deutsch, P., "DEFLATE Compressed Data Format Specification 276 version 1.3", RFC 1951, May 1996. 278 [6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. 280 [7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, 281 December 1998. 283 [8] Gutmann, P., "Compressed Data Content Type for Cryptographic 284 Message Syntax (CMS)", RFC 3274, June 2002. 286 Author's Address 288 Scott Hollenbeck 289 VeriSign, Inc. 290 21345 Ridgetop Circle 291 Dulles, VA 20166-6503 292 US 294 EMail: shollenbeck@verisign.com 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 intellectual property or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; neither does it represent that it 303 has made any effort to identify any such rights. Information on the 304 IETF's procedures with respect to rights in standards-track and 305 standards-related documentation can be found in BCP-11. Copies of 306 claims of rights made available for publication and any assurances of 307 licenses to be made available, or the result of an attempt made to 308 obtain a general license or permission for the use of such 309 proprietary rights by implementors or users of this specification can 310 be obtained from the IETF Secretariat. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights which may cover technology that may be required to practice 315 this standard. Please address the information to the IETF Executive 316 Director. 318 Full Copyright Statement 320 Copyright (C) The Internet Society (2004). All Rights Reserved. 322 This document and translations of it may be copied and furnished to 323 others, and derivative works that comment on or otherwise explain it 324 or assist in its implementation may be prepared, copied, published 325 and distributed, in whole or in part, without restriction of any 326 kind, provided that the above copyright notice and this paragraph are 327 included on all such copies and derivative works. However, this 328 document itself may not be modified in any way, such as by removing 329 the copyright notice or references to the Internet Society or other 330 Internet organizations, except as needed for the purpose of 331 developing Internet standards in which case the procedures for 332 copyrights defined in the Internet Standards process must be 333 followed, or as required to translate it into languages other than 334 English. 336 The limited permissions granted above are perpetual and will not be 337 revoked by the Internet Society or its successors or assignees. 339 This document and the information contained herein is provided on an 340 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 341 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 342 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 343 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 344 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Acknowledgment 348 Funding for the RFC Editor function is currently provided by the 349 Internet Society.