draft-ietf-tls-compression-02.txt   draft-ietf-tls-compression-03.txt 
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Updates: 2246 (if approved) October 7, 2002 Updates: 2246 (if approved) October 23, 2002
Expires: April 7, 2003 Expires: April 23, 2003
Transport Layer Security Protocol Compression Methods Transport Layer Security Protocol Compression Methods
draft-ietf-tls-compression-02.txt draft-ietf-tls-compression-03.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 April 7, 2003. This Internet-Draft will expire on April 23, 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 4 skipping to change at page 2, line 6
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. This document describes record protocol will not be compressed. This document describes
additional compression methods associated with lossless data additional compression methods associated with lossless data
compression algorithms for use with TLS. compression algorithms for use with TLS.
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
2.1 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Compression History and Packet Processing . . . . . . . . . . 5
2.2 LZS Compression . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5
3. Intellectual Property Considerations . . . . . . . . . . . . . 6 2.3 LZS Compression . . . . . . . . . . . . . . . . . . . . . . . 5
4. Internationalization Considerations . . . . . . . . . . . . . 7 3. Intellectual Property Considerations . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Internationalization Considerations . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
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 51 skipping to change at page 4, line 51
description of intellectual property considerations). ZLIB is description of intellectual property considerations). ZLIB is
generally known as a freely-available, widely-deployed compression generally known as a freely-available, widely-deployed compression
method, whereas LZS is generally known to provide memory footprint method, whereas LZS is generally known to provide memory footprint
and performance advantages in stateful networking applications. 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.
stateful to take advantage of the state management features offered
by TLS.
2.1 ZLIB Compression All of the compression methods described in this document are
stateful. It is recommended that other compression methods that
might be standardized in the future be stateful as well.
2.1 Compression History and Packet Processing
Some compression methods have the ability to maintain history
information when compressing and decompressing packet payloads. The
compression history allows a higher compression ratio to be achieved
on a stream as compared to per-packet compression, but maintaining a
history across packets implies that a packet might contain data
needed to completely decompress data contained in a different packet.
History maintenance thus requires both a reliable link and sequenced
packet delivery. History information MAY be maintained and exploited
when using the compression methods described in this document if TLS
is being used with a protocol that provides reliable, sequenced
packet delivery.
2.2 ZLIB Compression
The ZLIB compression method and encoding format is described in RFC The ZLIB compression method and encoding format is described in RFC
1950 [5] and RFC 1951 [6]. Examples of ZLIB use in IETF protocols 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]. can be found in RFC 1979 [7], RFC 2394 [8], and RFC 3274 [9].
ZLIB allows the sending compressor to select from among several ZLIB allows the sending compressor to select from among several
options to provide varying compression ratios, processing speeds, and options to provide varying compression ratios, processing speeds, and
memory requirements. The receiving decompressor will automatically memory requirements. The receiving decompressor will automatically
adjust to the parameters selected by the sender. adjust to the parameters selected by the sender.
The sender MUST flush the compressor completely each time a ZLIB has the ability to maintain history information when compressing
compressed payload is produced. All data that was submitted for and decompressing packet payloads. If TLS is not being used with a
compression MUST be included in the compressed output, with no data protocol that provides reliable, sequenced packet delivery, the
retained to be included in a later output payload. Flushing ensures sender MUST flush the compressor completely each time a compressed
that each payload is complete so that compressed packet payloads can payload is produced. All data that was submitted for compression
be decompressed independently. MUST be included in the compressed output, with no data retained to
be included in a later output payload. Flushing ensures that each
compressed packet payload can be decompressed completely.
2.2 LZS Compression 2.3 LZS Compression
The Lempel Zif Stac (LZS) compression method and encoding format is The Lempel Zif Stac (LZS) compression method and encoding format is
described in ANSI publication X3.241 [10]. Examples of LZS use in 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 IETF protocols can be found in RFC 1967 [11], RFC 1974 [12], and RFC
2395 [13]. 2395 [13].
LZS has the ability to maintain history information when compressing LZS has the ability to maintain history information when compressing
and decompressing packet payloads. When used with TLS, the and decompressing packet payloads. If TLS is not being used with a
protocol that provides reliable, sequenced packet delivery, the
compression history MUST be reset by the sender before compressing compression history MUST be reset by the sender before compressing
data and the decompression history MUST be reset by the receiver data and the decompression history MUST be reset by the receiver
before decompressing data to ensure that compressed packet payloads before decompressing data to ensure that compressed packet payloads
can be decompressed independently. can be decompressed completely. The sender MUST flush the compressor
completely each time a compressed payload is produced. All data that
The sender MUST flush the compressor completely each time a was submitted for compression MUST be included in the compressed
compressed payload is produced. All data that was submitted for output, with no data retained to be included in a later output
compression MUST be included in the compressed output, with no data payload. Flushing ensures that each compressed packet payload can be
retained to be included in a later output payload. Flushing ensures decompressed completely.
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.
skipping to change at page 9, line 11 skipping to change at page 10, 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.
Depending on the ciphersuite, symmetric encryption in TLS does not Some symmetric encryption ciphersuites do not hide the length of
fully hide the length of symmetrically encrypted data. Use of TLS symmetrically encrypted data at all. Others hide it to some extent,
compression SHOULD take into account that the length of compressed but still don't hide it fully. Use of TLS compression SHOULD take
data may leak more information than the length of the original into account that the length of compressed data may leak more
uncompressed data. information than the length of the original uncompressed data.
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, Alexey Melnikov, and Bodo Moeller.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999. 1999.
 End of changes. 

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