doc/protocol/rfc3749.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      S. Hollenbeck
   8 Request for Comments: 3749                                VeriSign, Inc.
   9 Category: Standards Track                                       May 2004
  10
  11
  12
  13          Transport Layer Security Protocol Compression Methods
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2004).  All Rights Reserved.
  26
  27 Abstract
  28
  29    The Transport Layer Security (TLS) protocol (RFC 2246) includes
  30    features to negotiate selection of a lossless data compression method
  31    as part of the TLS Handshake Protocol and to then apply the algorithm
  32    associated with the selected method as part of the TLS Record
  33    Protocol.  TLS defines one standard compression method which
  34    specifies that data exchanged via the record protocol will not be
  35    compressed.  This document describes an additional compression method
  36    associated with a lossless data compression algorithm for use with
  37    TLS, and it describes a method for the specification of additional
  38    TLS compression methods.
  39
  40 Table of Contents
  41
  42    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  43    2.  Compression Methods  . . . . . . . . . . . . . . . . . . . . .  2
  44        2.1.  DEFLATE Compression. . . . . . . . . . . . . . . . . . .  3
  45    3.  Compression History and Packet Processing  . . . . . . . . . .  4
  46    4.  Internationalization Considerations  . . . . . . . . . . . . .  4
  47    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
  48    6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
  49    7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
  50    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  51        8.1.  Normative References . . . . . . . . . . . . . . . . . .  6
  52        8.2.  Informative References . . . . . . . . . . . . . . . . .  6
  53        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
  54        Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
  55
  56
  57
  58 Hollenbeck                  Standards Track                     [Page 1]
  59 \f
  60 RFC 3749                TLS Compression Methods                 May 2004
  61
  62
  63 1.  Introduction
  64
  65    The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
  66    features to negotiate selection of a lossless data compression method
  67    as part of the TLS Handshake Protocol and to then apply the algorithm
  68    associated with the selected method as part of the TLS Record
  69    Protocol.  TLS defines one standard compression method,
  70    CompressionMethod.null, which specifies that data exchanged via the
  71    record protocol will not be compressed.  While this single
  72    compression method helps ensure that TLS implementations are
  73    interoperable, the lack of additional standard compression methods
  74    has limited the ability of implementers to develop interoperable
  75    implementations that include data compression.
  76
  77    TLS is used extensively to secure client-server connections on the
  78    World Wide Web.  While these connections can often be characterized
  79    as short-lived and exchanging relatively small amounts of data, TLS
  80    is also being used in environments where connections can be long-
  81    lived and the amount of data exchanged can extend into thousands or
  82    millions of octets.  XML [4], for example, is increasingly being used
  83    as a data representation method on the Internet, and XML tends to be
  84    verbose.  Compression within TLS is one way to help reduce the
  85    bandwidth and latency requirements associated with exchanging large
  86    amounts of data while preserving the security services provided by
  87    TLS.
  88
  89    This document describes an additional compression method associated
  90    with a lossless data compression algorithm for use with TLS.
  91    Standardization of the compressed data formats and compression
  92    algorithms associated with this compression method is beyond the
  93    scope of this document.
  94
  95    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  96    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  97    document are to be interpreted as described in RFC 2119 [1].
  98
  99 2.  Compression Methods
 100
 101    TLS [2] includes the following compression method structure in
 102    sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
 103
 104    enum { null(0), (255) } CompressionMethod;
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Hollenbeck                  Standards Track                     [Page 2]
 115 \f
 116 RFC 3749                TLS Compression Methods                 May 2004
 117
 118
 119    which allows for later specification of up to 256 different
 120    compression methods.  This definition is updated to segregate the
 121    range of allowable values into three zones:
 122
 123    1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
 124       reserved for IETF Standards Track protocols.
 125
 126    2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
 127       are reserved for assignment for non-Standards Track methods.
 128
 129    3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
 130       inclusive are reserved for private use.
 131
 132    Additional information describing the role of the IANA in the
 133    allocation of compression method identifiers is described in Section
 134    5.
 135
 136    In addition, this definition is updated to include assignment of an
 137    identifier for the DEFLATE compression method:
 138
 139    enum { null(0), DEFLATE(1), (255) } CompressionMethod;
 140
 141    As described in section 6 of RFC 2246 [2], TLS is a stateful
 142    protocol.  Compression methods used with TLS can be either stateful
 143    (the compressor maintains its state through all compressed records)
 144    or stateless (the compressor compresses each record independently),
 145    but there seems to be little known benefit in using a stateless
 146    compression method within TLS.
 147
 148    The DEFLATE compression method described in this document is
 149    stateful.  It is RECOMMENDED that other compression methods that
 150    might be standardized in the future be stateful as well.
 151
 152    Compression algorithms can occasionally expand, rather than compress,
 153    input data.  A compression method that exceeds the expansion limits
 154    described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.
 155
 156 2.1.  DEFLATE Compression
 157
 158    The DEFLATE compression method and encoding format is described in
 159    RFC 1951 [5].  Examples of DEFLATE use in IETF protocols can be found
 160    in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8].
 161
 162    DEFLATE allows the sending compressor to select from among several
 163    options to provide varying compression ratios, processing speeds, and
 164    memory requirements.  The receiving decompressor MUST automatically
 165    adjust to the parameters selected by the sender.  All data that was
 166    submitted for compression MUST be included in the compressed output,
 167
 168
 169
 170 Hollenbeck                  Standards Track                     [Page 3]
 171 \f
 172 RFC 3749                TLS Compression Methods                 May 2004
 173
 174
 175    with no data retained to be included in a later output payload.
 176    Flushing ensures that each compressed packet payload can be
 177    decompressed completely.
 178
 179 3.  Compression History and Packet Processing
 180
 181    Some compression methods have the ability to maintain state/history
 182    information when compressing and decompressing packet payloads.  The
 183    compression history allows a higher compression ratio to be achieved
 184    on a stream as compared to per-packet compression, but maintaining a
 185    history across packets implies that a packet might contain data
 186    needed to completely decompress data contained in a different packet.
 187    History maintenance thus requires both a reliable link and sequenced
 188    packet delivery.  Since TLS and lower-layer protocols provide
 189    reliable, sequenced packet delivery, compression history information
 190    MAY be maintained and exploited if supported by the compression
 191    method.
 192
 193    As described in section 7 of RFC 2246 [2], TLS allows multiple
 194    connections to be instantiated using the same session through the
 195    resumption feature of the TLS Handshake Protocol.  Session resumption
 196    has operational implications when multiple compression methods are
 197    available for use within the session.  For example, load balancers
 198    will need to maintain additional state information if the compression
 199    state is not cleared when a session is resumed.  As a result, the
 200    following restrictions MUST be observed when resuming a session:
 201
 202    1.  The compression algorithm MUST be retained when resuming a
 203        session.
 204
 205    2.  The compression state/history MUST be cleared when resuming a
 206        session.
 207
 208 4.  Internationalization Considerations
 209
 210    The compression method identifiers specified in this document are
 211    machine-readable numbers.  As such, issues of human
 212    internationalization and localization are not introduced.
 213
 214 5.  IANA Considerations
 215
 216    Section 2 of this document describes a registry of compression method
 217    identifiers to be maintained by the IANA, including assignment of an
 218    identifier for the DEFLATE compression method.  Identifier values
 219    from the range 0-63 (decimal) inclusive are assigned via RFC 2434
 220    Standards Action [3].  Values from the range 64-223 (decimal)
 221
 222
 223
 224
 225
 226 Hollenbeck                  Standards Track                     [Page 4]
 227 \f
 228 RFC 3749                TLS Compression Methods                 May 2004
 229
 230
 231    inclusive are assigned via RFC 2434 Specification Required [3].
 232    Identifier values from 224-255 (decimal) inclusive are reserved for
 233    RFC 2434 Private Use [3].
 234
 235 6.  Security Considerations
 236
 237    This document does not introduce any topics that alter the threat
 238    model addressed by TLS.  The security considerations described
 239    throughout RFC 2246 [2] apply here as well.
 240
 241    However, combining compression with encryption can sometimes reveal
 242    information that would not have been revealed without compression:
 243    data that is the same length before compression might be a different
 244    length after compression, so adversaries that observe the length of
 245    the compressed data might be able to derive information about the
 246    corresponding uncompressed data.  Some symmetric encryption
 247    ciphersuites do not hide the length of symmetrically encrypted data
 248    at all.  Others hide it to some extent, but still do not hide it
 249    fully.  For example, ciphersuites that use stream cipher encryption
 250    without padding do not hide length at all; ciphersuites that use
 251    Cipher Block Chaining (CBC) encryption with padding provide some
 252    length hiding, depending on how the amount of padding is chosen.  Use
 253    of TLS compression SHOULD take into account that the length of
 254    compressed data may leak more information than the length of the
 255    original uncompressed data.
 256
 257    Compression algorithms tend to be mathematically complex and prone to
 258    implementation errors.  An implementation error that can produce a
 259    buffer overrun introduces a potential security risk for programming
 260    languages and operating systems that do not provide buffer overrun
 261    protections.  Careful consideration should thus be given to
 262    protections against implementation errors that introduce security
 263    risks.
 264
 265    As described in Section 2, compression algorithms can occasionally
 266    expand, rather than compress, input data.  This feature introduces
 267    the ability to construct rogue data that expands to some enormous
 268    size when compressed or decompressed.  RFC 2246 describes several
 269    methods to ameliorate this kind of attack.  First, compression has to
 270    be lossless.  Second, a limit (1,024 bytes) is placed on the amount
 271    of allowable compression content length increase.  Finally, a limit
 272    (2^14 bytes) is placed on the total content length.  See section
 273    6.2.2 of RFC 2246 [2] for complete details.
 274
 275
 276
 277
 278
 279
 280
 281
 282 Hollenbeck                  Standards Track                     [Page 5]
 283 \f
 284 RFC 3749                TLS Compression Methods                 May 2004
 285
 286
 287 7.  Acknowledgements
 288
 289    The concepts described in this document were originally discussed on
 290    the IETF TLS working group mailing list in December, 2000.  The
 291    author acknowledges the contributions to that discussion provided by
 292    Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen.  Later
 293    suggestions that have been incorporated into this document were
 294    provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos
 295    Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the
 296    IESG.
 297
 298 8.  References
 299
 300 8.1.  Normative References
 301
 302    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 303         Levels", BCP 14, RFC 2119, March 1997.
 304
 305    [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 306         2246, January 1999.
 307
 308    [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 309         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 310
 311 8.2.  Informative References
 312
 313    [4]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
 314         "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
 315         October 2000, <http://www.w3.org/TR/REC-xml>.
 316
 317    [5]  Deutsch, P., "DEFLATE Compressed Data Format Specification
 318         version 1.3", RFC 1951, May 1996.
 319
 320    [6]  Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
 321
 322    [7]  Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
 323         December 1998.
 324
 325    [8]  Gutmann, P., "Compressed Data Content Type for Cryptographic
 326         Message Syntax (CMS)", RFC 3274, June 2002.
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Hollenbeck                  Standards Track                     [Page 6]
 339 \f
 340 RFC 3749                TLS Compression Methods                 May 2004
 341
 342
 343 Author's Address
 344
 345    Scott Hollenbeck
 346    VeriSign, Inc.
 347    21345 Ridgetop Circle
 348    Dulles, VA  20166-6503
 349    US
 350
 351    EMail: shollenbeck@verisign.com
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Hollenbeck                  Standards Track                     [Page 7]
 395 \f
 396 RFC 3749                TLS Compression Methods                 May 2004
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2004).  This document is subject
 402    to the rights, licenses and restrictions contained in BCP 78, and
 403    except as set forth therein, the authors retain all their rights.
 404
 405    This document and the information contained herein are provided on an
 406    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 407    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 408    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 409    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 410    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 411    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 412
 413 Intellectual Property
 414
 415    The IETF takes no position regarding the validity or scope of any
 416    Intellectual Property Rights or other rights that might be claimed to
 417    pertain to the implementation or use of the technology described in
 418    this document or the extent to which any license under such rights
 419    might or might not be available; nor does it represent that it has
 420    made any independent effort to identify any such rights.  Information
 421    on the procedures with respect to rights in RFC documents can be
 422    found in BCP 78 and BCP 79.
 423
 424    Copies of IPR disclosures made to the IETF Secretariat and any
 425    assurances of licenses to be made available, or the result of an
 426    attempt made to obtain a general license or permission for the use of
 427    such proprietary rights by implementers or users of this
 428    specification can be obtained from the IETF on-line IPR repository at
 429    http://www.ietf.org/ipr.
 430
 431    The IETF invites any interested party to bring to its attention any
 432    copyrights, patents or patent applications, or other proprietary
 433    rights that may cover technology that may be required to implement
 434    this standard.  Please address the information to the IETF at ietf-
 435    ipr@ietf.org.
 436
 437 Acknowledgement
 438
 439    Funding for the RFC Editor function is currently provided by the
 440    Internet Society.
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Hollenbeck                  Standards Track                     [Page 8]
 451 \f