Network Working Group S. Hollenbeck
Request for Comments: 3749 VeriSign, Inc.
Category: Standards Track May 2004
Network Working Group S. Hollenbeck
Request for Comments: 3749 VeriSign, Inc.
Category: Standards Track May 2004
Transport Layer Security Protocol Compression Methods
传输层安全协议压缩方法
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods.
传输层安全（TLS）协议（RFC 2246）包括用于协商作为TLS握手协议的一部分的无损数据压缩方法的选择，以及随后应用与所选方法相关联的算法作为TLS记录协议的一部分的特征。TLS定义了一种标准压缩方法，该方法规定通过记录协议交换的数据不会被压缩。本文档描述了与用于TLS的无损数据压缩算法相关联的附加压缩方法，并描述了用于规范附加TLS压缩方法的方法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 2
2.1. DEFLATE Compression. . . . . . . . . . . . . . . . . . . 3
3. Compression History and Packet Processing . . . . . . . . . . 4
4. Internationalization Considerations . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 2
2.1. DEFLATE Compression. . . . . . . . . . . . . . . . . . . 3
3. Compression History and Packet Processing . . . . . . . . . . 4
4. Internationalization Considerations . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, CompressionMethod.null, which specifies that data exchanged via the record protocol will not be compressed. While this single compression method helps ensure that TLS implementations are interoperable, the lack of additional standard compression methods has limited the ability of implementers to develop interoperable implementations that include data compression.
传输层安全（TLS）协议（RFC 2246，[2]）包括用于协商作为TLS握手协议的一部分的无损数据压缩方法的选择，以及随后应用与所选方法相关联的算法作为TLS记录协议的一部分的特征。TLS定义了一种标准压缩方法CompressionMethod.null，它指定通过记录协议交换的数据不会被压缩。虽然这种单一的压缩方法有助于确保TLS实现是可互操作的，但缺乏额外的标准压缩方法限制了实现者开发包括数据压缩在内的可互操作实现的能力。
TLS is used extensively to secure client-server connections on the World Wide Web. While these connections can often be characterized as short-lived and exchanging relatively small amounts of data, TLS is also being used in environments where connections can be long-lived and the amount of data exchanged can extend into thousands or millions of octets. XML [4], for example, is increasingly being used as a data representation method on the Internet, and XML tends to be verbose. Compression within TLS is one way to help reduce the bandwidth and latency requirements associated with exchanging large amounts of data while preserving the security services provided by TLS.
TLS广泛用于保护万维网上的客户机-服务器连接。虽然这些连接通常可以被描述为短命的，并且交换的数据量相对较小，但TLS也被用于连接寿命较长且交换的数据量可以扩展到数千或数百万个八位字节的环境中。例如，XML[4]在互联网上越来越多地被用作数据表示方法，XML往往过于冗长。TLS内的压缩是帮助减少与交换大量数据相关的带宽和延迟要求的一种方法，同时保留TLS提供的安全服务。
This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS. Standardization of the compressed data formats and compression algorithms associated with this compression method is beyond the scope of this document.
本文档描述了与TLS使用的无损数据压缩算法相关的附加压缩方法。与此压缩方法相关的压缩数据格式和压缩算法的标准化超出了本文档的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
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:
TLS[2]包括第6.1节和第7.4.1.2节以及附录A.4.1和A.6节中的以下压缩方法结构：
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
which allows for later specification of up to 256 different compression methods. This definition is updated to segregate the range of allowable values into three zones:
它允许以后指定多达256种不同的压缩方法。更新此定义以将允许值范围分为三个区域：
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols.
1. 0（零）到63位小数（0x3F）之间的值保留给IETF标准跟踪协议。
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods.
2. 保留从64位小数（0x40）到223位小数（0xDF）的值，用于非标准轨迹方法的赋值。
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use.
3. 从224位小数（0xE0）到255位小数（0xFF）的值保留供私人使用。
Additional information describing the role of the IANA in the allocation of compression method identifiers is described in Section 5.
第5节描述了描述IANA在压缩方法标识符分配中的作用的附加信息。
In addition, this definition is updated to include assignment of an identifier for the DEFLATE compression method:
此外，此定义已更新，以包括放气压缩方法标识符的分配：
enum { null(0), DEFLATE(1), (255) } CompressionMethod;
enum { null(0), DEFLATE(1), (255) } CompressionMethod;
As described in section 6 of RFC 2246 [2], TLS is a stateful protocol. Compression methods used with TLS can be either stateful (the compressor maintains its 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.
如RFC 2246[2]第6节所述，TLS是一种有状态协议。TLS使用的压缩方法可以是有状态的（压缩器通过所有压缩记录保持其状态）或无状态的（压缩器独立压缩每个记录），但在TLS中使用无状态压缩方法似乎没有什么好处。
The DEFLATE compression method described in this document is stateful. It is RECOMMENDED that other compression methods that might be standardized in the future be stateful as well.
本文档中描述的放气压缩方法是有状态的。建议将来可能标准化的其他压缩方法也是有状态的。
Compression algorithms can occasionally expand, rather than compress, 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.
压缩算法有时会扩展而不是压缩输入数据。超过RFC 2246[2]第6.2.2节所述膨胀极限的压缩方法不得用于TLS。
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].
RFC 1951[5]中描述了放气压缩方法和编码格式。IETF协议中使用DEFLATE的示例可在RFC 1979[6]、RFC 2394[7]和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,
DEFLATE允许发送压缩器从多个选项中进行选择，以提供不同的压缩比、处理速度和内存要求。接收解压缩程序必须自动调整到发送方选择的参数。提交压缩的所有数据必须包含在压缩输出中，
with no data retained to be included in a later output payload. Flushing ensures that each compressed packet payload can be decompressed completely.
没有保留要包含在以后输出有效负载中的数据。刷新确保每个压缩的数据包有效负载都可以完全解压缩。
Some compression methods have the ability to maintain state/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. Since TLS and lower-layer protocols provide reliable, sequenced packet delivery, compression history information MAY be maintained and exploited if supported by the compression method.
某些压缩方法在压缩和解压缩数据包有效负载时能够维护状态/历史信息。与每个分组压缩相比，压缩历史允许在流上实现更高的压缩比，但是跨分组维护历史意味着分组可能包含完全解压缩包含在不同分组中的数据所需的数据。因此，历史记录维护需要可靠的链路和有序的数据包交付。由于TLS和较低层协议提供了可靠的、有序的数据包交付，如果压缩方法支持，则可以维护和利用压缩历史信息。
As described in section 7 of RFC 2246 [2], TLS allows multiple connections to be instantiated using the same session through the resumption feature of the TLS Handshake Protocol. Session resumption has operational implications when multiple compression methods are available for use within the session. For example, load balancers will need to maintain additional state information if the compression state is not cleared when a session is resumed. As a result, the following restrictions MUST be observed when resuming a session:
如RFC 2246[2]第7节所述，TLS允许通过TLS握手协议的恢复功能使用同一会话实例化多个连接。当会话中有多种压缩方法可供使用时，会话恢复会产生操作影响。例如，如果会话恢复时未清除压缩状态，负载平衡器将需要维护其他状态信息。因此，恢复会话时必须遵守以下限制：
1. The compression algorithm MUST be retained when resuming a session.
1. 恢复会话时必须保留压缩算法。
2. The compression state/history MUST be cleared when resuming a session.
2. 恢复会话时必须清除压缩状态/历史记录。
The compression method identifiers specified in this document are machine-readable numbers. As such, issues of human internationalization and localization are not introduced.
本文档中指定的压缩方法标识符是机器可读的数字。因此，没有引入人的国际化和本地化问题。
Section 2 of this document describes a registry of compression method identifiers to be maintained by the IANA, including assignment of an identifier for the DEFLATE compression method. Identifier values from the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action [3]. Values from the range 64-223 (decimal)
本文件第2节描述了IANA将维护的压缩方法标识符注册表，包括为DEFLATE压缩方法分配标识符。0-63（十进制）范围内的标识符值通过RFC 2434标准操作[3]分配。范围64-223（十进制）的值
inclusive are assigned via RFC 2434 Specification Required [3]. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use [3].
包括通过RFC 2434指定的所需规范[3]。224-255（十进制）的标识符值保留给RFC 2434专用[3]。
This document does not introduce any topics that alter the threat model addressed by TLS. The security considerations described throughout RFC 2246 [2] apply here as well.
本文件不介绍任何改变TLS所述威胁模型的主题。RFC 2246[2]中描述的安全注意事项也适用于此处。
However, combining compression with encryption can sometimes reveal information that would not have been revealed without compression: data that is the same length before compression might be a different length after compression, so adversaries that observe the length of 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 do not 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.
但是，将压缩与加密相结合有时会显示未经压缩无法显示的信息：压缩前长度相同的数据在压缩后可能长度不同，因此，观察压缩数据长度的对手可能能够获得有关相应未压缩数据的信息。某些对称加密密码套件根本不隐藏对称加密数据的长度。其他人在某种程度上隐藏了它，但仍然没有完全隐藏它。例如，使用无填充的流密码加密的密码套件根本不隐藏长度；使用带填充的密码块链接（CBC）加密的密码套件提供了一些长度隐藏，具体取决于填充量的选择方式。使用TLS压缩时应考虑到压缩数据的长度可能比原始未压缩数据的长度泄漏更多的信息。
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.
如第2节所述，压缩算法有时可以扩展而不是压缩输入数据。此功能引入了构造恶意数据的能力，这些数据在压缩或解压缩时会扩展到一些巨大的大小。RFC 2246描述了几种改进此类攻击的方法。首先，压缩必须是无损的。其次，对允许的压缩内容长度增加量进行限制（1024字节）。最后，对总内容长度进行限制（2^14字节）。完整详情见RFC 2246[2]第6.2.2节。
The concepts described in this document were originally discussed on the IETF TLS working group mailing list in December, 2000. The author acknowledges the contributions to that discussion provided by 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, Elgin Lee, Nikos Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the IESG.
本文件中描述的概念最初于2000年12月在IETF TLS工作组邮件列表中讨论。作者感谢Jeffrey Altman、Eric Rescorla和Marc Van Heyningen对该讨论的贡献。后来，Tim Dierks、Pasi Eronen、Peter Gutmann、Elgin Lee、Nikos Mavroyanopoulos、Alexey Melnikov、Bodo Moeller、Win Treese和IESG提出了纳入本文件的建议。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[4] Bray，T.，Paoli，J.，Sperberg McQueen，C.和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC XML，2000年10月<http://www.w3.org/TR/REC-xml>.
[5] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[5] Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
[6] 伍兹，J.，“购买力平价平减协议”，RFC 1979，1996年8月。
[7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[7] 佩雷拉，R.，“使用DEFLATE压缩IP有效载荷”，RFC 23941998年12月。
[8] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[8] Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
Author's Address
作者地址
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。