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
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は、World Wide Web上のクライアント・サーバー接続を確保するために広く使用されています。これらの接続は、しばしば、短命と比較的少量のデータを交換するように特徴付けることができるが、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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; 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:
列挙{ヌル（0）、（255）} CompressionMethod。これまでに256個の異なる圧縮方法の後の仕様を可能にします。この定義は、3つのゾーンに許容値の範囲を分離するように更新されます。
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols.
包括的な63進（は0x3F）を介して、0（ゼロ）から1の値は、IETF標準化過程プロトコルのために予約されています。
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods.
64進（0x40の）から包括223小数（0xDF）を介して2値は、非標準化過程法の割り当てのために予約されています。
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use.
224小数（0xE0となって）から包括255小数（0xff）の3値は、私的使用のために予約されています。
Additional information describing the role of the IANA in the allocation of compression method identifiers is described in Section 5.
圧縮方式識別子の割当てにおいてIANAの役割を記述する追加情報は、セクション5に記載されています。
In addition, this definition is updated to include assignment of an identifier for the DEFLATE compression method:
また、この定義はDEFLATE圧縮方法の識別子の割り当てを含むように更新されます。
enum { null(0), DEFLATE(1), (255) } CompressionMethod;
列挙{ヌル（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のセクション6で説明したように、[2]、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.
このドキュメントで説明するDEFLATE圧縮方法は、ステートフルです。将来的に標準化されるかもしれない他の圧縮方法も同様ステートフルすることをお勧めします。
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のセクション6.2.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].
DEFLATE圧縮方式と符号化フォーマットは、RFC 1951年に記載されている[5]。 DEFLATEの例は、[7] RFC 2394 [6] RFC 1979年に見出すことができるIETFプロトコルにおいて使用し、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.
DEFLATEは、送信側の圧縮機は、様々な圧縮率、処理速度、およびメモリ要件を提供するために、いくつかのオプションの中から選択することができます。受信減圧装置は、自動的に送信者によって選択されたパラメータを調整しなければなりません。データが後で出力ペイロードに含まれるように保持していないとの圧縮のために提出されたすべてのデータは、圧縮された出力に含まれなければなりません。フラッシングは、各圧縮されたパケットのペイロードが完全に解凍することができることを確実にします。
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は、圧縮方式識別子のレジストリがDEFLATE圧縮方法の識別子の割り当てを含む、IANAによって維持されるように記載されています。範囲0-63（10進数）包括から識別子値は、RFC 2434規格作用を介して割り当てられている[3]。範囲64から223（10進数）からの値
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（10進数）の識別子の値は、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.
この文書に記載された概念は、もともと12月にIETF TLSワーキンググループのメーリングリストで議論された、2000年著者はジェフリー・アルトマン、エリックレスコラ、およびマーク・ヴァンHeyningenによって提供される議論への貢献を認めています。本文書に組み込まれている、後の提案はティム・ダークス、パシEronen、ピーター・ガットマン、エルジン・リー、ニコスMavroyanopoulos、アレクセイ・メルニコフ、ボードーメラー、勝つTreese、およびIESGによって提供されました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2]ダークス、T.とC.アレン、 "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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、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]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月を。
[6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
[6]ウッズ、J.、 "PPPデフレートプロトコル"、RFC 1979、1996年8月。
[7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[7]ペレイラ、R.、 "DEFLATEを使用するIPペイロード圧縮"、RFC 2394、1998年12月。
[8] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[8]、RFC 3274 Gutmann氏、P.、 "暗号メッセージ構文（CMS）のための圧縮データのコンテンツタイプ" を、2002年6月。
Author's Address
著者のアドレス
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
スコットホレンベックベリサイン社21345 Ridgetopサークルダレス、バージニア州20166から6503米
EMail: shollenbeck@verisign.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。