draft-ietf-tls-compression-01.txt   draft-ietf-tls-compression-02.txt 
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Updates: 2246 (if approved) September 20, 2002 Updates: 2246 (if approved) October 7, 2002
Expires: March 21, 2003 Expires: April 7, 2003
Transport Layer Security Protocol Compression Methods Transport Layer Security Protocol Compression Methods
draft-ietf-tls-compression-01.txt draft-ietf-tls-compression-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2003. This Internet-Draft will expire on April 7, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The Transport Layer Security (TLS) protocol (RFC 2246) includes The Transport Layer Security (TLS) protocol (RFC 2246) includes
features to negotiate selection of a lossless data compression method features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm as part of the TLS Handshake Protocol and to then apply the algorithm
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Conventions Used In This Document Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 4 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 4
3. Intellectual Property Considerations . . . . . . . . . . . . . 5 2.1 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5
4. Internationalization Considerations . . . . . . . . . . . . . 6 2.2 LZS Compression . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3. Intellectual Property Considerations . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Internationalization Considerations . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
features to negotiate selection of a lossless data compression method features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record associated with the selected method as part of the TLS Record
Protocol. TLS defines one standard compression method, Protocol. TLS defines one standard compression method,
CompressionMethod.null, which specifies that data exchanged via the CompressionMethod.null, which specifies that data exchanged via the
record protocol will not be compressed. While this single record protocol will not be compressed. While this single
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Additional information describing the role of the IANA in the Additional information describing the role of the IANA in the
allocation of compression method identifiers is described in Section allocation of compression method identifiers is described in Section
5. 5.
In addition, this definition is updated to include assignment of two In addition, this definition is updated to include assignment of two
additional compression methods: additional compression methods:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod; enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
The ZLIB compression method is described in RFC 1950 [5] and RFC 1951 These two compression methods are defined to provide implementers
[6]. The Lempel Zif Stac (LZS) compression method is described in with alternatives based on compression performance, ease of
ANSI publication X3.241 [7]. implementation, and licensing requirements (see Section 3 for a
description of intellectual property considerations). ZLIB is
generally known as a freely-available, widely-deployed compression
method, whereas LZS is generally known to provide memory footprint
and performance advantages in stateful networking applications.
As described in section 6 of RFC 2246, TLS is a stateful protocol. As described in section 6 of RFC 2246, TLS is a stateful protocol.
Compression methods used with TLS can be either stateful (the Compression methods used with TLS can be either stateful (the
compressor maintains it's state through all compressed records) or compressor maintains it's state through all compressed records) or
stateless (the compressor compresses each record independently), but stateless (the compressor compresses each record independently), but
there seems to be little known benefit in using a stateless there seems to be little known benefit in using a stateless
compression method within TLS. Compression methods SHOULD be compression method within TLS. Compression methods SHOULD be
stateful to take advantage of the state management features offered stateful to take advantage of the state management features offered
by TLS. by TLS.
2.1 ZLIB Compression
The ZLIB compression method and encoding format is described in RFC
1950 [5] and RFC 1951 [6]. Examples of ZLIB use in IETF protocols
can be found in RFC 1979 [7], RFC 2394 [8], and RFC 3274 [9].
ZLIB allows the sending compressor to select from among several
options to provide varying compression ratios, processing speeds, and
memory requirements. The receiving decompressor will automatically
adjust to the parameters selected by the sender.
The sender MUST flush the compressor completely each time a
compressed payload is produced. All data that was submitted for
compression MUST be included in the compressed output, with no data
retained to be included in a later output payload. Flushing ensures
that each payload is complete so that compressed packet payloads can
be decompressed independently.
2.2 LZS Compression
The Lempel Zif Stac (LZS) compression method and encoding format is
described in ANSI publication X3.241 [10]. Examples of LZS use in
IETF protocols can be found in RFC 1967 [11], RFC 1974 [12], and RFC
2395 [13].
LZS has the ability to maintain history information when compressing
and decompressing packet payloads. When used with TLS, the
compression history MUST be reset by the sender before compressing
data and the decompression history MUST be reset by the receiver
before decompressing data to ensure that compressed packet payloads
can be decompressed independently.
The sender MUST flush the compressor completely each time a
compressed payload is produced. All data that was submitted for
compression MUST be included in the compressed output, with no data
retained to be included in a later output payload. Flushing ensures
that each payload is complete so that compressed packet payloads can
be decompressed independently.
3. Intellectual Property Considerations 3. Intellectual Property Considerations
Many compression algorithms are subject to patent or other Many compression algorithms are subject to patent or other
intellectual property rights claims. Implementers are encouraged to intellectual property rights claims. Implementers are encouraged to
seek legal guidance to better understand the implications of seek legal guidance to better understand the implications of
developing implementations of the compression methods described in developing implementations of the compression methods described in
this document or other documents that describe compression methods this document or other documents that describe compression methods
for use with TLS. for use with TLS.
4. Internationalization Considerations 4. Internationalization Considerations
skipping to change at page 8, line 11 skipping to change at page 9, line 11
policy described in RFC 2434. Values from the general IANA pool MUST policy described in RFC 2434. Values from the general IANA pool MUST
be assigned according to the "IETF Consensus" policy described in RFC be assigned according to the "IETF Consensus" policy described in RFC
2434. 2434.
6. Security Considerations 6. Security Considerations
This document does not introduce any topics that alter the threat This document does not introduce any topics that alter the threat
model addressed by TLS. The security considerations described model addressed by TLS. The security considerations described
throughout RFC 2246 [2] apply here as well. throughout RFC 2246 [2] apply here as well.
Data compression prior to encryption typically "flattens" the Depending on the ciphersuite, symmetric encryption in TLS does not
distribution of unencrypted octets (or very slightly increases the fully hide the length of symmetrically encrypted data. Use of TLS
unicity distance) by using fewer bits to represent common characters. compression SHOULD take into account that the length of compressed
An increase in unicity distance typically indicates an increase in data may leak more information than the length of the original
the amount of work required of an attacker to recover the original uncompressed data.
plaintext. However, compression methods often require a structured
header at the beginning of the compressed data stream, giving an
attacker a target for testing keys in a brute force search.
Compression can thus decrease and not increase the security of
encryption if an attacker has little prior knowledge of the original
plaintext.
7. Acknowledgements 7. Acknowledgements
The concepts described in this document were originally discussed on The concepts described in this document were originally discussed on
the IETF TLS working group mailing list in December, 2000. The the IETF TLS working group mailing list in December, 2000. The
author acknowledges the contributions to that discussion provided by author acknowledges the contributions to that discussion provided by
Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later
suggestions that have been incorporated into this document were suggestions that have been incorporated into this document were
provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Nikos provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Nikos
Mavroyanopoulos, and Bodo Moeller. Mavroyanopoulos, and Bodo Moeller.
skipping to change at page 11, line 17 skipping to change at page 12, line 17
[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <http://www.w3.org/TR/REC-xml>. October 2000, <http://www.w3.org/TR/REC-xml>.
[5] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [5] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
[6] Deutsch, P., "DEFLATE Compressed Data Format Specification [6] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[7] American National Standards Institute, "Data Compression Method, [7] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
Adaptive Coding with Sliding Window of Information Interchange",
ANSI X3.241, 1994. [8] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
December 1998.
[9] Gutmann, P., "Compressed Data Content Type for Cryptographic
Message Syntax (CMS)", RFC 3274, June 2002.
[10] American National Standards Institute, "Data Compression
Method, Adaptive Coding with Sliding Window of Information
Interchange", ANSI X3.241, 1994.
[11] Schneider, K., Friend, R. and K. Fox, "PPP LZS-DCP Compression
Protocol (LZS-DCP)", RFC 1967, August 1996.
[12] Friend, R., Simpson, W. and K. Fox, "PPP Stac LZS Compression
Protocol", RFC 1974, August 1996.
[13] Friend, R. and R. Monsour, "IP Payload Compression Using LZS",
RFC 2395, December 1998.
Author's Address Author's Address
Scott Hollenbeck Scott Hollenbeck
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
US US
EMail: shollenbeck@verisign.com EMail: shollenbeck@verisign.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/