draft-ietf-tls-compression-05.txt   draft-ietf-tls-compression-06.txt 
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Updates: 2246 (if approved) May 27, 2003 Updates: 2246 (if approved) November 20, 2003
Expires: November 25, 2003 Expires: May 20, 2004
Transport Layer Security Protocol Compression Methods Transport Layer Security Protocol Compression Methods
draft-ietf-tls-compression-05.txt draft-ietf-tls-compression-06.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 November 25, 2003. This Internet-Draft will expire on May 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 9, line 11 skipping to change at page 9, line 11
described in RFC 2434. Values from the general IANA pool MUST be described in RFC 2434. Values from the general IANA pool MUST be
assigned according to the "IETF Consensus" policy described in RFC 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.
Some symmetric encryption ciphersuites do not hide the length of However, combining compression with encryption can sometimes reveal
symmetrically encrypted data at all. Others hide it to some extent, information that would not have been revealed without compression:
but still don't hide it fully. Use of TLS compression SHOULD take data that is the same length before compression might be a different
into account that the length of compressed data may leak more length after compression, so adversaries that observe the length of
information than the length of the original uncompressed data. the compressed data might be able to derive information about the
corresponding uncompressed data. Some symmetric encryption
ciphersuites do not hide the length of symmetrically encrypted data
at all. Others hide it to some extent, but still don't hide it
fully. For example, ciphersuites that use stream cipher encryption
without padding do not hide length at all; ciphersuites that use
Cipher Block Chaining (CBC) encryption with padding provide some
length hiding, depending on how the amount of padding is chosen. Use
of TLS compression SHOULD take into account that the length of
compressed data may leak more 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, Elgin Lee, Nikos provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos
Mavroyanopoulos, Alexey Melnikov, and Bodo Moeller. Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, and Win Treese.
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 14, line 7 skipping to change at page 14, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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