draft-ietf-tls-compression-00.txt   draft-ietf-tls-compression-01.txt 
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: March 6, 2003 September 5, 2002 Updates: 2246 (if approved) September 20, 2002
Expires: March 21, 2003
Transport Layer Security Protocol Compression Methods Transport Layer Security Protocol Compression Methods
draft-ietf-tls-compression-00.txt draft-ietf-tls-compression-01.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 31 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 6, 2003. This Internet-Draft will expire on March 21, 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 4, line 33 skipping to change at page 4, line 33
values MUST be made by the IANA and MUST be associated with a values MUST be made by the IANA and MUST be associated with a
formal reference that describes the compression method. formal reference that describes the compression method.
3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are 3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are
reserved for private use. reserved for private use.
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 In addition, this definition is updated to include assignment of two
three additional compression methods: additional compression methods:
enum { null(0), ZLIB(1), LZS(2), RLE(3), (255) } CompressionMethod; enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
The ZLIB compression method is described in RFC 1950 [5]. The Lempel The ZLIB compression method is described in RFC 1950 [5] and RFC 1951
Zif Stac (LZS) compression method is described in ANSI publication [6]. The Lempel Zif Stac (LZS) compression method is described in
X3-241 [6]. The Run Length Encoding (RLE) compression method is ANSI publication X3.241 [7].
described in part 5 of the Digital Imaging and Communications in
Medicine standard [7]. As described in section 6 of RFC 2246, TLS is a stateful protocol.
Compression methods used with TLS can be either stateful (the
compressor maintains it's state through all compressed records) or
stateless (the compressor compresses each record independently), but
there seems to be little known benefit in using a stateless
compression method within TLS. Compression methods SHOULD be
stateful to take advantage of the state management features offered
by TLS.
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. this document or other documents that describe compression methods
for use with TLS.
4. Internationalization Considerations 4. Internationalization Considerations
The compression method identifiers specified in this document are The compression method identifiers specified in this document are
machine-readable numbers. As such, issues of human machine-readable numbers. As such, issues of human
internationalization and localization are not introduced. internationalization and localization are not introduced.
5. IANA Considerations 5. IANA Considerations
This document does not have a direct impact on the IANA, but it does This document does not have a direct impact on the IANA, but it does
skipping to change at page 8, line 8 skipping to change at page 8, line 8
the TLS working group MUST be assigned according to the "Standards the TLS working group MUST be assigned according to the "Standards
Action" policy described in RFC 2434 [3]. Values from the range Action" policy described in RFC 2434 [3]. Values from the range
reserved for private use MUST be used according to the "Private Use" reserved for private use MUST be used according to the "Private Use"
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. However, data compression prior to model addressed by TLS. The security considerations described
encryption can potentially provide a security benefit in "flattening" throughout RFC 2246 [2] apply here as well.
the distribution of unencrypted octets (or increasing the unicity
distance) by using fewer bits to represent common characters. In Data compression prior to encryption typically "flattens" the
situations where the unencrypted octets represent human-readable distribution of unencrypted octets (or very slightly increases the
text, reducing the predictability of text patterns can make it unicity distance) by using fewer bits to represent common characters.
slightly more difficult to mount a successful attack on the encrypted An increase in unicity distance typically indicates an increase in
octets. the amount of work required of an attacker to recover the original
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. Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later
suggestions that have been incorporated into this document were
provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Nikos
Mavroyanopoulos, 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.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Informative References Informative References
[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] American National Standards Institute, "Data Compression Method, [6] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[7] American National Standards Institute, "Data Compression Method,
Adaptive Coding with Sliding Window of Information Interchange", Adaptive Coding with Sliding Window of Information Interchange",
ANSI X3.241, 1994. ANSI X3.241, 1994.
[7] National Electrical Manufacturers Association, "Digital Imaging
and Communications in Medicine (DICOM) Part 5: Data Structures
and Encoding", 2001, <http://medical.nema.org/dicom/2001/
01_05PU.PDF>.
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/