< draft-ietf-tls-compression-06.txt		draft-ietf-tls-compression-07.txt >
	Network Working Group S. Hollenbeck		Network Working Group S. Hollenbeck
	Internet-Draft VeriSign, Inc.		Internet-Draft VeriSign, Inc.
	Updates: 2246 (if approved) November 20, 2003		Updates: 2246 (if approved) January 16, 2004
	Expires: May 20, 2004		Expires: July 16, 2004
	Transport Layer Security Protocol Compression Methods		Transport Layer Security Protocol Compression Methods
	draft-ietf-tls-compression-06.txt		draft-ietf-tls-compression-07.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 May 20, 2004.		This Internet-Draft will expire on July 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). 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
	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 which		Protocol. TLS defines one standard compression method which
	specifies that data exchanged via the record protocol will not be		specifies that data exchanged via the record protocol will not be
	compressed. This document describes an additional compression method		compressed. This document describes an additional compression method
	skipping to change at page 2, line 14 ¶		skipping to change at page 2, line 14 ¶
	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 . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Compression History and Packet Processing . . . . . . . . . . 5		2.1 DEFLATE Compression . . . . . . . . . . . . . . . . . . . . . 4
	2.2 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5		3. Compression History and Packet Processing . . . . . . . . . . 4
	3. Intellectual Property Considerations . . . . . . . . . . . . . 6		4. Internationalization Considerations . . . . . . . . . . . . . 5
	4. Internationalization Considerations . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		Normative References . . . . . . . . . . . . . . . . . . . . . 6
	Normative References . . . . . . . . . . . . . . . . . . . . . 11		Informative References . . . . . . . . . . . . . . . . . . . . 7
	Informative References . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . 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 17 ¶		skipping to change at page 3, line 49 ¶
	TLS [2] includes the following compression method structure in		TLS [2] includes the following compression method structure in
	sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:		sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
	enum { null(0), (255) } CompressionMethod;		enum { null(0), (255) } CompressionMethod;
	which allows for later specification of up to 256 different		which allows for later specification of up to 256 different
	compression methods. This definition is updated to segregate the		compression methods. This definition is updated to segregate the
	range of allowable values into three zones:		range of allowable values into three zones:
	1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are		1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
	reserved for future standardization efforts of the IETF TLS		reserved for IETF Standards Track protocols.
	working group.
	2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are		2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
	reserved for assignment by the IANA for specifications developed		inclusive are reserved for assignment for non-Standards Track
	outside the TLS working group. Assignments from this range of		methods.
	values MUST be made by the IANA and MUST be associated with a
	formal reference that describes the compression method.
	3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are		3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
	reserved for private use.		inclusive are 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 an		In addition, this definition is updated to include assignment of an
	identifier for the ZLIB compression method:		identifier for the DEFLATE compression method:
	enum { null(0), ZLIB(1), (255) } CompressionMethod;		enum { null(0), DEFLATE(1), (255) } CompressionMethod;
	As described in section 6 of RFC 2246 [2], TLS is a stateful		As described in section 6 of RFC 2246 [2], TLS is a stateful
	protocol. Compression methods used with TLS can be either stateful		protocol. Compression methods used with TLS can be either stateful
	(the compressor maintains it's state through all compressed records)		(the compressor maintains its state through all compressed records)
	or stateless (the compressor compresses each record independently),		or stateless (the compressor compresses each record independently),
	but there seems to be little known benefit in using a stateless		but there seems to be little known benefit in using a stateless
	compression method within TLS.		compression method within TLS.
	The ZLIB compression method described in this document is stateful.		The DEFLATE compression method described in this document is
	It is recommended that other compression methods that might be		stateful. It is RECOMMENDED that other compression methods that might
	standardized in the future be stateful as well.		be standardized in the future be stateful as well.
	Compression algorithms can occasionally expand, rather than compress,		Compression algorithms can occasionally expand, rather than compress,
	input data. A compression method that exceeds the expansion limits		input data. A compression method that exceeds the expansion limits
	described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.		described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.
	2.1 Compression History and Packet Processing		2.1 DEFLATE Compression
	Some compression methods have the ability to maintain history		The DEFLATE compression method and encoding format is described in
			RFC 1951 [5]. Examples of DEFLATE use in IETF protocols can be found
			in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8].
			DEFLATE allows the sending compressor to select from among several
			options to provide varying compression ratios, processing speeds, and
			memory requirements. The receiving decompressor MUST automatically
			adjust to the parameters selected by the sender. 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 compressed packet payload can be
			decompressed completely.
			3. Compression History and Packet Processing
			Some compression methods have the ability to maintain state/history
	information when compressing and decompressing packet payloads. The		information when compressing and decompressing packet payloads. The
	compression history allows a higher compression ratio to be achieved		compression history allows a higher compression ratio to be achieved
	on a stream as compared to per-packet compression, but maintaining a		on a stream as compared to per-packet compression, but maintaining a
	history across packets implies that a packet might contain data		history across packets implies that a packet might contain data
	needed to completely decompress data contained in a different packet.		needed to completely decompress data contained in a different packet.
	History maintenance thus requires both a reliable link and sequenced		History maintenance thus requires both a reliable link and sequenced
	packet delivery. Since TLS and lower-layer protocols provide		packet delivery. Since TLS and lower-layer protocols provide
	reliable, sequenced packet delivery, compression history information		reliable, sequenced packet delivery, compression history information
	MAY be maintained and exploited if supported by the compression		MAY be maintained and exploited if supported by the compression
	method.		method.
	2.2 ZLIB Compression		As described in section 7 of RFC 2246 [2], TLS allows multiple
			connections to be instantiated using the same session through the
	The ZLIB compression method and encoding format is described in RFC		resumption feature of the TLS Handshake Protocol. Session resumption
	1950 [5] and RFC 1951 [6]. Examples of ZLIB use in IETF protocols can		has operational implications when multiple compression methods are
	be found in RFC 1979 [7], RFC 2394 [8], and RFC 3274 [9].		available for use within the session. For example, load balancers
			will need to maintain additional state information if the compression
	ZLIB allows the sending compressor to select from among several		state is not cleared when a session is resumed. As a result, the
	options to provide varying compression ratios, processing speeds, and		following restrictions MUST be observed when resuming a session:
	memory requirements. The receiving decompressor MUST automatically
	adjust to the parameters selected by the sender. 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 compressed packet payload can be
	decompressed completely.
	3. Intellectual Property Considerations		1. The compression algorithm MUST be retained when resuming a
			session.
	Many compression algorithms are subject to patent or other		2. The compression state/history MUST be cleared when resuming a
	intellectual property rights claims. Implementers are encouraged to		session.
	seek legal guidance to better understand the implications of
	developing implementations of the compression method described in
	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
	Section 2 of this document describes a registry of compression method		Section 2 of this document describes a registry of compression method
	identifiers to be maintained by the IANA, including assignment of an		identifiers to be maintained by the IANA, including assignment of an
	identifier for the ZLIB compression method. Identifier values from		identifier for the DEFLATE compression method. Identifier values
	the range reserved for future standardization efforts of the TLS		from the range 0-63 (decimal) inclusive are assigned via RFC 2434
	working group MUST be assigned according to the "Standards Action"		Standards Action [3]. Values from the range 64-223 (decimal)
	policy described in RFC 2434 [3]. Values from the range reserved for		inclusive are assigned via RFC 2434 Specification Required [3].
	private use MUST be used according to the "Private Use" policy		Identifier values from 224-255 (decimal) inclusive are reserved for
	described in RFC 2434. Values from the general IANA pool MUST be		RFC 2434 Private Use [3].
	assigned according to the "IETF Consensus" policy described in RFC
	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.
	However, combining compression with encryption can sometimes reveal		However, combining compression with encryption can sometimes reveal
	information that would not have been revealed without compression:		information that would not have been revealed without compression:
	data that is the same length before compression might be a different		data that is the same length before compression might be a different
	skipping to change at page 10, line 5 ¶		skipping to change at page 6, line 21 ¶
	ciphersuites do not hide the length of symmetrically encrypted data		ciphersuites do not hide the length of symmetrically encrypted data
	at all. Others hide it to some extent, but still don't hide it		at all. Others hide it to some extent, but still don't hide it
	fully. For example, ciphersuites that use stream cipher encryption		fully. For example, ciphersuites that use stream cipher encryption
	without padding do not hide length at all; ciphersuites that use		without padding do not hide length at all; ciphersuites that use
	Cipher Block Chaining (CBC) encryption with padding provide some		Cipher Block Chaining (CBC) encryption with padding provide some
	length hiding, depending on how the amount of padding is chosen. Use		length hiding, depending on how the amount of padding is chosen. Use
	of TLS compression SHOULD take into account that the length of		of TLS compression SHOULD take into account that the length of
	compressed data may leak more information than the length of the		compressed data may leak more information than the length of the
	original uncompressed data.		original uncompressed data.
			Compression algorithms tend to be mathematically complex and prone to
			implementation errors. An implementation error that can produce a
			buffer overrun introduces a potential security risk for programming
			languages and operating systems that do not provide buffer overrun
			protections. Careful consideration should thus be given to
			protections against implementation errors that introduce security
			risks.
			As described in Section 2, compression algorithms can occasionally
			expand, rather than compress, input data. This feature introduces
			the ability to construct rogue data that expands to some enormous
			size when compressed or decompressed. RFC 2246 describes several
			methods to ameliorate this kind of attack. First, compression has to
			be lossless. Second, a limit (1,024 bytes) is placed on the amount of
			allowable compression content length increase. Finally, a limit
			(2^14 bytes) is placed on the total content length. See section
			6.2.2 of RFC 2246 [2] for complete details.
	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, Bodo Moeller, and Win Treese.		Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the
			IESG.
	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. and C. Allen, "The TLS Protocol Version 1.0", RFC
	P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January		2246, January 1999.
	1999.
	[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	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, P., "DEFLATE Compressed Data Format Specification
	Specification version 3.3", RFC 1950, May 1996.
	[6] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
	[7] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.		[6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
	[8] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,		[7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
	December 1998.		December 1998.
	[9] Gutmann, P., "Compressed Data Content Type for Cryptographic		[8] Gutmann, P., "Compressed Data Content Type for Cryptographic
	Message Syntax (CMS)", RFC 3274, June 2002.		Message Syntax (CMS)", RFC 3274, June 2002.
	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
	skipping to change at page 13, line 29 ¶		skipping to change at page 8, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 26 change blocks.
	75 lines changed or deleted		90 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/