Network Working Group R. Friend
Request for Comments: 3943 Hifn
Category: Informational November 2004
Transport Layer Security (TLS) Protocol Compression Using
Lempel-Ziv-Stac (LZS)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（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 then to 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 the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol.
トランスポート層セキュリティ（TLS）プロトコル（RFC 2246）は、TLSハンドシェイクプロトコルの一部として無損失データ圧縮方式の選択を交渉するために、次にTLSレコードプロトコルの一部として選択された方法に関連したアルゴリズムを適用する機能を含みます。 TLSレコード・プロトコルを介して交換されるデータが圧縮されないことを指定する一つの標準圧縮方式を定義しています。この文書では、TLSで使用するためのLempel-Ziv符号-のStac（LZS）無損失データ圧縮アルゴリズムに関連する追加の圧縮方法を記載しています。また、このドキュメントでは、TLSレコードプロトコルへのLZSアルゴリズムの適用を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Specification of Requirements. . . . . . . . . . . . . . 3
2. Compression Methods. . . . . . . . . . . . . . . . . . . . . . 3
2.1. LZS CompresionMethod . . . . . . . . . . . . . . . . . . 4
2.2. Security Issues with Single History Compression. . . . . 4
3. LZS Compression. . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Background of LZS Compression . . . . . . . . . . . . . 4
3.2. LZS Compression History and Record Processing . . . . . 5
3.3. LZS Compressed Record Format . . . . . . . . . . . . . . 6
3.4. TLSComp Header Format . . . . . . . . . . . . . . . . . 6
3.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . 6
3.5. LZS Compression Encoding Format . . . . . . . . . . . . 7
3.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Sending Compressed Records . . . . . . . . . . . . . . . . . . 8
4.1. Transmitter Process. . . . . . . . . . . . . . . . . . . 9
4.2. Receiver Process . . . . . . . . . . . . . . . . . . . . 9
4.3. Anti-expansion Mechanism . . . . . . . . . . . . . . . . 10
5. Internationalization Considerations . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
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 then to 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. Although this single compression method helps ensure that TLS implementations are interoperable, the lack of additional standard compression methods has limited the ability to develop interoperative 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. Although 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. For example, TLS is now increasingly being used as an alternative Virtual Private Network (VPN) connection. Compression services have long been associated with IPSec and PPTP VPN connections, so extending compression services to TLS VPN connections preserves the user experience for any VPN connection. 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はまた、接続が長寿命であることができ、交換されるデータの量は、オクテットの数千または数百万の中に延びることができる環境で使用されています。例えば、TLSは今やますます別の仮想プライベートネットワーク（VPN）接続として使用されています。圧縮サービスは長いので、TLS VPN接続に圧縮サービスを拡張し、IPSecとPPTP VPN接続に関連付けられているすべてのVPN接続のためのユーザーエクスペリエンスを維持してきました。 TLS内の圧縮は、TLSによって提供されるセキュリティサービスを維持しながら、大量のデータをやり取りに関連した帯域幅と遅延の要件を軽減する一つの方法です。
This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS. This document specifies the application of Lempel-Ziv-Stac (LZS) compression, a lossless compression algorithm, to TLS record payloads. This specification also assumes a thorough understanding of the TLS protocol [2].
この文書では、TLSで使用するための無損失データ圧縮アルゴリズムに関連する追加の圧縮方法を記載しています。この文書では、TLSレコードのペイロードへのLempel-Ziv-Stac（LZS）圧縮、可逆圧縮アルゴリズムの適用を指定します。本明細書はまた、TLSプロトコル[2]の完全な理解を前提としています。
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 BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
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. The LZS compression method described in this document is stateful.
RFC 2246のセクション6で説明したように、[2]、TLSは、ステートフルプロトコルです。 TLSで使用される圧縮方法は、（圧縮機は、それぞれ独立してレコードを圧縮）ステートフル（圧縮機は、すべての圧縮レコードをその状態を維持する）、またはステートレスのいずれかであってもよいが、TLS内のステートレス圧縮方法を使用することにあまり知られていない利益があるように思われることができます。このドキュメントで説明LZS圧縮方法は、ステートフルです。
Compression algorithms can occasionally expand, rather than compress, input data. The worst-case expansion factor of the LZS compression method is only 12.5%. Thus, TLS records of 15K bytes can never exceed the expansion limits described in section 6.2.2 of RFC 2246 [2]. If TLS records of 16K bytes expand to an amount greater than 17K bytes, then the uncompressed version of the TLS record must be transmitted, as described below.
圧縮アルゴリズムは時折、入力されたデータを展開するのではなく、圧縮することができます。 LZS圧縮方式の最悪の場合の拡張係数はわずか12.5％です。したがって、15KバイトのTLSレコードはRFC 2246のセクション6.2.2に記載の膨張の制限を超えないことができる[2]。 16KバイトのTLSレコードが17Kバイトを超える量に展開すると、以下に記載されるように、次いで、TLSレコードの非圧縮バージョンは、送信されなければなりません。
The LZS CompressionMethod is a 16-bit index and is negotiated as described in RFC 2246 [2] and RFC 3749 [3]. The LZS CompressionMethod is stored in the TLS Record Layer connection state as described in RFC 2246 [2].
LZS CompressionMethod [3] [2]及びRFC 3749 16ビットのインデックスであり、RFC 2246に記載されるように交渉されます。 RFC 2246に記載されているようにLZS CompressionMethodは、TLSレコード層接続状態に格納されている[2]。
IANA has assigned 64 as compression method identifier for applying LZS compression to TLS record payloads.
IANAは、TLSレコードのペイロードにLZS圧縮を適用するための圧縮方式識別子として64を割り当てています。
Sharing compression histories between or among more than one TLS session may potentially cause information leakage between the TLS sessions, as pathological compressed data can potentially reference data prior to the beginning of the current record. LZS implementations guard against this situation. However, to avoid this potential threat, implementations supporting TLS compression MUST use separate compression histories for each TLS session. This is not a limitation of LZS compression but is an artifact for any compression algorithm.
病理学的な圧縮されたデータは、潜在的に現在のレコードの先頭に前のデータを参照できるように複数のTLSセッションの間、または間で圧縮履歴を共有することは、潜在的に、TLSセッションの間で情報漏洩を引き起こす可能性があります。 LZS実装は、このような状況を防ぎます。しかし、この潜在的な脅威を回避するために、TLSの圧縮をサポートする実装は、各TLSセッションのために別々の圧縮履歴を使用しなければなりません。これは、LZS圧縮を限定するものではないが、任意の圧縮アルゴリズムのアーチファクトです。
Furthermore, the LZS compression history (as well as any compression history) contains plaintext. Specifically, the LZS history contains the last 2K bytes of plaintext of the TLS session. Thus, when the TLS session terminates, the implementation SHOULD treat the history as it does any plaintext (e.g., free memory, overwrite contents).
また、LZS圧縮履歴（ならびに任意の圧縮履歴）平文を含んでいます。具体的には、LZS履歴はTLSセッションの平文の最後の2Kバイトが含まれています。 TLSセッションが終了したとき、それはすべての平文と同様にこのように、実装は歴史を扱うべきである（例えば、空きメモリ、内容を上書き）。
Starting with a sliding window compression history, similar to LZ1 [8], a new, enhanced compression algorithm identified as LZS was developed. The LZS algorithm is a general-purpose lossless compression algorithm for use with a wide variety of data types. Its encoding method is very efficient, providing compression for strings as short as two octets in length.
[8]、LZSとして識別新しい、強化された圧縮アルゴリズムが開発されたLZ1と同様に、スライディングウィンドウ圧縮の歴史から始まります。 LZSアルゴリズムは、データタイプの様々なと共に使用するための汎用の可逆圧縮アルゴリズムです。その符号化方法は、長さが2つのオクテットほど短い文字列の圧縮を提供する、非常に効率的です。
The LZS algorithm uses a sliding window of 2,048 bytes. During compression, redundant sequences of data are replaced with tokens that represent those sequences. During decompression, the original sequences are substituted for the tokens in such a way that the original data is exactly recovered. LZS differs from lossy compression algorithms, such as those often used for video compression, that do not exactly reproduce the original data. The details of LZS compression can be found in section 3.5 below.
LZSアルゴリズムは、2,048バイトのスライディングウィンドウを使用します。圧縮時に、データの冗長配列はこれらの配列を表すトークンで置き換えられます。減圧中に、元の配列は、元のデータを正確に回復されるようにトークンに置換されています。 LZSは正確に元のデータを再生しないように、多くの場合、ビデオ圧縮のために使用されるものなどの非可逆圧縮アルゴリズム、とは異なります。 LZS圧縮の詳細は、以下のセクション3.5に記載されています。
This standard specifies "stateful" compression -- that is, maintaining the compression history between records within a particular TLS compression session. Within each separate compression history, the LZS CompressionMethod can maintain compression history information when compressing and decompressing record payloads. Stateful compression provides a higher compression ratio to be achieved on the data stream, as compared to stateless compression (resetting the compression history between every record), particularly for small records.
特定のTLS圧縮セッション内のレコード間の圧縮履歴を維持すること、である - この規格は、「ステートフル」圧縮を指定します。レコードのペイロードを圧縮して解凍する際に、各個別の圧縮歴史の中で、LZS CompressionMethodは、圧縮履歴情報を維持することができます。ステートフルな圧縮は、特に小さなレコードを、（すべてのレコード間の圧縮履歴をリセットする）ステートレス圧縮と比較して、データ・ストリーム上で達成されるより高い圧縮比を提供します。
Stateful compression requires both a reliable link and sequenced record delivery to ensure that all records can be decompressed in the same order they were compressed. Since TLS and lower-layer protocols provide reliable, sequenced record delivery, compression history information MAY be maintained and exploited when the LZS CompressionMethod is used.
ステートフル圧縮はすべてのレコードは、彼らが圧縮されたのと同じ順序で解凍できることを保証するために、信頼性の高いリンクし、配列決定したレコードの配信の両方が必要です。 TLSと下位層プロトコルは信頼性、配列決定したレコードの配信を提供するためLZS CompressionMethodを使用した場合、圧縮履歴情報を維持し、利用することができます。
Furthermore, there MUST be a separate LZS compression history associated with each open TLS session. This not only provides enhanced security (no potential information leakage between sessions via a shared compression history), but also enables superior compression ratio (bit bandwidth on the connection) across all open TLS sessions with compression. A shared history would require resetting the compression (and decompression) history when switching between TLS sessions, and a single history implementation would require resetting the compression (and decompression) history between each record.
また、各オープンTLSセッションに関連付けられた別LZS圧縮履歴がなければなりません。これは、セキュリティの強化（共有圧縮履歴を介したセッションの間には潜在的な情報漏洩）を提供するだけでなく、圧縮して、開いているすべてのTLSセッション間で優れた圧縮率（接続上のビット帯域幅）を有効にしないだけ。共有履歴は、TLSセッションを切り替えるときの圧縮（および減圧）履歴のリセットが必要となる、単一の履歴の実装は、各レコード間の圧縮（および減圧）履歴をリセットする必要があろう。
The sender MUST reset the compression history prior to compressing the first TLS record of a TLS session after TLS handshake completes. It is advantageous for the sender to maintain the compression history for all subsequent records processed during the TLS session. This results in the greatest compression ratio for a given data set. In either case, this compression history MUST NOT be used for any other open TLS session, to ensure privacy between TLS sessions.
送信者は、前TLSハンドシェイクが完了した後、TLSセッションの最初のTLSレコードを圧縮する圧縮履歴をリセットする必要があります。送信者がTLSセッション中に処理された後続のすべてのレコードの圧縮履歴を維持することが有利です。これは、所与のデータ・セットの最大圧縮比をもたらします。いずれの場合も、この圧縮履歴は、TLSセッションの間でプライバシーを確保するために、他の開いているTLSセッションのために使用してはいけません。
The sender MUST "flush" the compressor each time it transmits a compressed record. Flushing means that all data going into the compressor is included in the output, i.e., no data is retained in the hope of achieving better compression. Flushing ensures that each compressed record payload can be decompressed completely. Flushing is necessary to prevent a record's data from spilling over into a later record. This is important for synchronizing compressed data with the authenticated and encrypted data in a TLS record. Flushing is handled automatically in most LZS implementations.
送信者は、「フラッシュ」コンプレッサが圧縮されたレコードを送信するたびにする必要があります。フラッシングは、コンプレッサに入るすべてのデータが出力に含まれることを意味する、すなわち、データは、より良い圧縮を達成するための希望に保持されていません。フラッシングは、各圧縮レコードのペイロードが完全に解凍することができることを確実にします。フラッシングは、後にレコードにこぼれるからのレコードのデータを防止する必要があります。これは、TLSレコードで認証および暗号化されたデータと圧縮されたデータを同期させるために重要です。フラッシングは、ほとんどのLZS実装で自動的に処理されます。
When the TLS session terminates, the implementation SHOULD dispose of the memory resources associated with the related TLS compression history. That is, the compression history SHOULD be handled as the TLS key material is handled.
TLSセッションが終了すると、インプリメンテーションは、関連TLSの圧縮履歴に関連するメモリリソースを処分すべきです。 TLS鍵材料が処理されるようにそれは、圧縮履歴が処理されるべきれます。
The LZS CompressionMethod also features "decompressing" uncompressed data in order to maintain the history if the "compressed" data actually expanded. The LZS CompressionMethod record format facilitates identifying whether records contain compressed or uncompressed data. The LZS decoding process accommodates decompressing either compressed or uncompressed data.
LZS CompressionMethodまた、「圧縮」のデータが実際に展開されている場合の歴史を維持するために、非圧縮データを「解凍」しています。 LZS CompressionMethodレコード形式は、レコードは、圧縮または非圧縮データを含むかどうかを同定が容易になります。 LZS復号処理は、圧縮または非圧縮のいずれかのデータを伸張収容します。
Prior to compression, the uncompressed data (TLSPlaintext.fragment) is composed of a plaintext TLS record. After compression, the compressed data (TLSCompressed.fragment) is composed of an 8-bit TLSComp header followed by the compressed (or uncompressed) data.
圧縮前に、非圧縮データ（のTLSPlaintext.fragment）は平文TLSレコードから構成されています。圧縮後、圧縮されたデータ（のTLSCompressed.fragment）は、圧縮された（または非圧縮）データに続く8ビットのTLSCompヘッダで構成されています。
The one-octet header has the following structure:
1オクテットのヘッダは、以下の構造を有します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Flags |
| |
+-+-+-+-+-+-+-+-+
The format of the 8-bit Flags TLSComp field is as follows:
次のように8ビットのフラグTLSCompフィールドの形式は次のとおりです。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | Res | Res | Res | Res | Res | RST | C/U |
+-----+-----+-----+-----+-----+-----+-----+-----+
Res-Reserved
RES-予約
Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node.
将来の使用のために予約されています。ゼロに設定しなければなりません。受信ノードによって無視されなければなりません。
RST-Reset Compression History
RST-リセット圧縮履歴
The RST bit is used to inform the decompressing peer that the compression history in this TLS session was reset prior to the data contained in this TLS record being compressed. When the RST bit is set to "1", a compression history reset is performed; when RST is set to "0", a compression history reset is not performed.
RSTビットは、このTLSセッションで圧縮履歴が前圧縮され、このTLSレコードに含まれるデータにリセットされたことを伸張ピアに通知するために使用されます。 RSTビットが「1」に設定されている場合、圧縮履歴のリセットが行われます。 RSTが「0」に設定されている場合、圧縮履歴のリセットは行われません。
This bit MUST be set to a value of "1" for the first compressed TLS transmitted record of a TLS session. This bit may also be used by the transmitter for other exception cases when the compression history must be reset.
このビットは、TLSセッションのレコードを送信し第1の圧縮TLSのための「1」の値に設定しなければなりません。圧縮履歴をリセットしなければならないとき、このビットは、他の例外のケースのために送信機によって使用されてもよいです。
C/U-Compressed/Uncompressed Bit
C / U-圧縮/非圧縮ビット
The C/U indicates whether the data field contains compressed or uncompressed data. A value of 1 indicates compressed data (often referred to as a compressed record), and a value of 0 indicates uncompressed data (or an uncompressed record).
C / Uは、データ・フィールドは圧縮または非圧縮データが含まれているかどうかを示します。 1の値は、（多くの場合、圧縮されたレコードと呼ばれる）圧縮されたデータを示し、0の値は、非圧縮データ（圧縮されていないレコード）を示します。
The LZS compression method, encoding format, and application examples are described in RFC 1967 [6], RFC 1974 [5], and RFC 2395 [4].
LZS圧縮方式、符号化方式、及び応用例は、RFC 1967に記載されている[6]、RFC 1974 [5]、およびRFC 2395 [4]。
Some implementations of LZS allow the sending compressor to select from among several options to provide varying compression ratios, processing speeds, and memory requirements. Other implementations of LZS provide optimal compression ratio at byte-per-clock speeds.
LZSのいくつかの実装は、送信側の圧縮機は、様々な圧縮率、処理速度、およびメモリ要件を提供するためにいくつかのオプションの中から選択することができます。 LZSの他の実装は、バイトあたりのクロック速度で最適な圧縮比を提供しています。
The receiving LZS decompressor automatically adjusts to the settings selected by the sender. Also, receiving LZS decompressors will update the decompression history with uncompressed data. This facilitates never obtaining less than a 1:1 compression ratio in the session and never transmitting with expanded data.
受信LZSは、デコンプレッサ自動的に送信者が選択した設定に調整します。また、LZS圧縮解除を受信すると、非圧縮データを解凍履歴を更新します。セッション1の圧縮比と決して拡張データを送信する：これは1未満を得ることはありませんが容易になります。
The input to the payload compression algorithm is TLSPlaintext data destined to an active TLS session with compression negotiated. The output of the algorithm is a new (and hopefully smaller) TLSCompressed record. The output payload contains the input payload's data in either compressed or uncompressed format. The input and output payloads are each an integral number of bytes in length.
ペイロード圧縮アルゴリズムへの入力は、ネゴシエートされた圧縮されたアクティブTLSセッション宛のTLSPlaintextデータです。アルゴリズムの出力は、レコードをTLSCompressed新しい（そして、できればより小さい）です。出力ペイロードには、圧縮または非圧縮のいずれかの形式で入力ペイロードのデータが含まれています。入力と出力のペイロードは、それぞれ長さがバイトの整数です。
The output payload is always prepended with the TLSComp header. If the uncompressed form is used, the output payload is identical to the input payload, and the TLSComp header reflects uncompressed data.
出力ペイロードは常にTLSCompヘッダが付加されています。非圧縮形式が使用される場合、出力ペイロードは入力ペイロードと同一であり、TLSCompヘッダ非圧縮データを反映しています。
If the compressed form is used, encoded as defined in ANSI X3.241 [7], and the TLSComp header reflects compressed data. The LZS encoded format is repeated here for informational purposes ONLY.
圧縮形式が使用される場合、ANSI X3.241 [7]で定義されるように符号化され、TLSCompヘッダが圧縮されたデータを反映しています。 LZSエンコード形式は、情報提供のみを目的としてここで繰り返されます。
<Compressed Stream> := [<Compressed String>*] <End Marker> <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<圧縮ストリーム>：= [<圧縮された文字列> * <エンドマーカー> <圧縮された文字列>：= 0 <生のバイト> | 1 <圧縮されたバイト>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte) <Compressed Bytes> := <Offset> <Length>
<生のバイト> = <B> <B> <B> <B> <B> <B> <B> <B>（8ビットバイト）<圧縮されたバイト> = <オフセット> <長さ>
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset) 0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset) <End Marker> := 110000000 <b> := 1 | 0
<オフセット>：= 1 <B> <B> <B> <B> <B> <B> <B> | （7ビットオフセット）0 <B> <B> <B> <B> <B> <B> <B> <B> <B> <B> <B>（11ビットオフセット）<エンドマーカー> ：= 110000000 <B>：= 1 | 0
<Length> := 00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13 ...
<長さ>：= = 2 00 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 = 1000 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 13 24 1111 0101を= ...
A datagram payload compressed with LZS always ends with the last compressed data byte (also known as the <end marker>), which is used to disambiguate padding. This allows trailing bits, as well as bytes, to be considered padding.
LZSで圧縮されたデータグラムのペイロードは常にパディングを明確にするために使用されている（また、<エンドマーカー>としても知られる）最後の圧縮データバイトで終わります。これは、パディング考慮すべき末尾ビット、ならびにバイトを、可能にします。
The size of a compressed payload MUST be in whole octet units.
圧縮されたペイロードのサイズは、全体のオクテット単位でなければなりません。
All TLS records processed with a TLS session state that includes LZS compression are processed as follows. The reliable and efficient transport of LZS compressed records in the TLS session depends on the following processes.
次のようにLZS圧縮を含んでTLSセッションの状態で処理されるすべてのTLSレコードが処理されます。 TLSセッションでLZS圧縮記録の信頼性と効率的な輸送には、以下のプロセスに依存します。
The compression operation results in either compressed or uncompressed data. When a TLS record is received, it is assigned to a particular TLS context that includes the LZS compression history buffer. It is processed according to ANSI X3.241-1994 to form compressed data or used as is to form uncompressed data. For the first record of the session, or for exception conditions, the compression history MUST be cleared. In performing the compression operation, the compression history MUST be updated when either a compressed record or an uncompressed record is produced. Uncompressed TLS records MAY be sent at any time. Uncompressed TLS records MUST be sent if compression causes enough expansion to make the data compression TLS record size exceed the MTU defined in section 6.2.2 in RFC 2246. The output of the compression operation is placed in the fragment field of the TLSCompressed structure (TLSCompressed.fragment).
圧縮操作は、圧縮または非圧縮データのいずれかをもたらします。 TLSレコードが受信されると、それはLZS圧縮ヒストリバッファを含む特定のTLSコンテキストに割り当てられています。これは、圧縮されたデータを形成するために、ANSI X3.241-1994に従って処理または非圧縮データを形成するように使用されます。セッションの最初のレコードの場合、または例外条件のために、圧縮履歴をクリアする必要があります。圧縮されたレコードまたは非圧縮レコードのいずれかが生成されるときに圧縮動作を行う際に、圧縮履歴を更新する必要があります。非圧縮TLSレコードは、任意の時点で送るかもしれません。圧縮されていないTLSレコードは、圧縮は、データ圧縮TLSレコードサイズを作るのに十分な膨張を引き起こす場合MTUは、圧縮動作の出力をTLSCompressed構造（TLSCompressedのフラグメント領域に配置されるRFC 2246にセクション6.2.2で定義された超えて送信されなければなりません。断片）。
The TLSComp header byte is located just prior to the first byte of the compressed TLS record in TLSCompressed.fragment. The C/U bit in the TLSComp header is set according to whether the data field contains compressed or uncompressed data. The RST bit in the TLSComp header is set to "1" if the compression history was reset prior to compressing the TLSplaintext.fragment that is composed of a TLSCompressed.fragment. Uncompressed data MUST be transmitted (and the C/U bit set to 0) if the "compressed" (expanded) data exceeded 17K bytes.
TLSCompヘッダバイトのTLSCompressed.fragment内の圧縮TLSレコードの最初のバイトの直前に配置されています。 TLSCompヘッダ内のC / Uビットはデータフィールドは圧縮または非圧縮データが含まれているかどうかに応じて設定されます。圧縮履歴が前のTLSCompressed.fragmentから構成されているのTLSPlaintext.fragment圧縮にリセットされた場合TLSCompヘッダーのRSTビットが「1」に設定されています。 「圧縮」（拡張）データは17Kバイトを超えた場合、非圧縮データが送信されなければならない（とC / Uは0に設定ビット）。
Prior to decompressing the first compressed TLS record in the TLS session, the receiver MUST reset the decompression history. Subsequent records are decompressed in the order received. The receiver decompresses the Payload Data field according to the encoding specified in section 3.5 above.
TLSセッションで最初に圧縮されたTLSレコードを解凍する前に、受信機は、圧縮解除履歴をリセットする必要があります。後続のレコードは、受信順に解凍されます。受信機は、上記のセクション3.5で指定されたエンコーディングに従ってペイロードデータフィールドを解凍します。
If the received datagram is not compressed, the receiver does not need to perform decompression processing, and the Payload Data field of the datagram is ready for processing by the next protocol layer.
受信したデータグラムが圧縮されていない場合、受信機は、伸張処理を実行する必要はなく、データグラムのペイロードデータフィールドは、次のプロトコル層の処理の準備ができています。
After a TLS record is received from the peer and decrypted, the RST and C/U bits MUST be checked.
TLSレコードがピアから受信され、復号化された後、RSTおよびC / Uビットをチェックしなければなりません。
If the C/U bit is set to "1", the resulting compressed data block MUST be decompressed according to section 3.5 above.
C / Uビットが「1」に設定されている場合、得られた圧縮データブロックは、上記のセクション3.5に従って解凍しなければなりません。
If the C/U bit is set to "0", the specified decompression history MUST be updated with the received uncompressed data.
C / Uビットが「0」に設定されている場合、指定された減圧履歴が受信された非圧縮データで更新されなければなりません。
If the RST bit is set to "1", the receiving decompression history MAY be reset to an initial state prior to decompressing the TLS record. (However, due to the characteristics of the Hifn LZS algorithm, a decompression history reset is not required). After reset, any compressed or uncompressed data contained in the record is processed.
RSTビットが「1」に設定されている場合は、受信解凍履歴は前TLSレコードを解凍する初期状態にリセットされることがあります。 （ただし、のhIFN LZSアルゴリズムの特性に起因し、減圧履歴のリセットが必要とされません）。リセット後、レコードに含まれる任意の圧縮または非圧縮データが処理されます。
During compression, there are two workable options for handling records that expand:
圧縮時には、拡張レコードを処理するための2つの実行可能なオプションがあります。
1) Send the expanded data (as long as TLSCompressed.length is 17K or less) and maintain the history, thus allowing loss of current bandwidth but preserving future bandwidth on the link.
1）TLSCompressed.lengthが17K以下である限り（拡張データを送信します）ので、現在の帯域幅の損失を許可するが、リンク上で、将来の帯域幅を維持し、歴史を維持します。
2) Send the uncompressed data and do not clear the compression history; the decompressor will update its history, thus conserving the current bandwidth and future bandwidth on the link.
2）非圧縮データを送信し、圧縮履歴をクリアしないでください。デコンプレッサは、このように、リンク上の現在の帯域幅と将来の帯域幅を節約、その歴史を更新します。
The second option is the preferred option and SHOULD be implemented.
第2のオプションは、好適なオプションであり、実施されるべきです。
There is a third option:
第三の選択肢があります：
3) Send the uncompressed data and clear the history, thus conserving current bandwidth but allowing possible loss of future bandwidth on the link.
3）このように現在の帯域幅を節約しますが、リンク上で、将来の帯域幅の損失の可能性を可能にすること、非圧縮データを送信し、履歴をクリア。
This option SHOULD NOT be implemented.
このオプションは実装されるべきではありません。
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 RFC 3749 [3] describes a registry of compression method identifiers to be maintained by the IANA and to be assigned within three zones.
RFC 3749のセクション2 [3]はIANAによって維持される三ゾーン内で割り当てられる圧縮方法識別子の登録が記載されています。
IANA has assigned an identifier for the LZS compression method from the RFC 2434 Specification Required IANA pool, as described in sections 2 and 5 of RFC 3749 [3].
セクション2及びRFC 3749の5で説明したようにIANAは、RFC 2434仕様が必要でIANAプールからLZS圧縮方式の識別子を割り当てられている[3]。
The IANA-assigned compression method identifier for LZS is 64 decimal (0x40).
LZSためのIANAによって割り当てられた圧縮方式識別子は、64進（0×40）です。
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 not 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圧縮の使用は、圧縮されたデータの長さが元の非圧縮データの長さよりもより多くの情報が漏洩する可能性を考慮すべきです。
Another security issue to be aware of is that the LZS compression history contains plaintext. In order to prevent any kind of information leakage outside the system, when a TLS session with compression terminates, the implementation SHOULD treat the compression history as it does plaintext -- that is, care should be taken not to reveal the compression history in any form or to use it again. This is described in sections 2.2 and 3.2 above.
注意すべきもう一つのセキュリティ問題は、LZS圧縮歴史が平文が含まれていることです。圧縮されたTLSセッションが終了したとき、それは平文を行うようにシステムの外部情報漏洩のあらゆる種類のを防ぐために、実装は、圧縮履歴を扱うべきである - つまり、ケアは任意の形式で圧縮履歴を明らかにしないように注意してくださいまたは、再びそれを使用します。これは、上記のセクション2.2および3.2に記載されています。
This information leakage concept can be extended to the situation of sharing a single compression history across more than one TLS session, as addressed in section 2.2 above.
上記セクション2.2で取り上げ、この情報漏洩の概念は、複数のTLSセッション全体で単一の圧縮履歴を共有する事態にまで拡張することができます。
Other security issues are discussed in RFC 3749 [3].
他のセキュリティ問題は、RFC 3749で説明されている[3]。
The concepts described in this document were derived from RFC 1967 [6], RFC 1974 [5], RFC 2395 [4], and RFC 3749 [3]. The author acknowledges the contributions of Scott Hollenbeck, Douglas Whiting, and Russell Dietz, and help from Steve Bellovin, Russ Housley, and Eric Rescorla.
本書で説明される概念は、RFC 1967に由来した[6]、RFC 1974 [5]、RFC 2395 [4]、及びRFC 3749 [3]。著者はスコットホレンベック、ダグラスホワイティング、およびラッセルディーツ、とスティーブBellovin氏、ラスHousley、およびエリックレスコラからの援助の貢献を認めています。
[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] Hollenbeck, S. "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[3]ホレンベック、S.、 "トランスポート層セキュリティプロトコル圧縮方法"、RFC 3749、2004年5月。
[4] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[4]フレンド、R.とR. Monsour、 "IPペイロード圧縮使い方LZS"、RFC 2395、1998年12月。
[5] Friend, R. and W. Simpson, "PPP Stac LZS Compression Protocol", RFC 1974, August 1996.
[5]フレンド、R.とW.シンプソン、 "PPPのStac LZS圧縮プロトコル"、RFC 1974、1996年8月。
[6] Schneider, K. and R. Friend, "PPP LZS-DCP Compression Protocol (LZS-DCP)", RFC 1967, August 1996.
[6]シュナイダー、K.とR.フレンド、 "PPP LZS-DCP圧縮プロトコル（LZS-DCP）"、RFC 1967、1996年8月。
[7] American National Standards Institute, Inc., "Data Compression Method for Information Systems," ANSI X3.241-1994, August 1994.
[7]米国規格協会、株式会社、「情報システムのためのデータ圧縮方法、」ANSI X3.241-1994、1994年8月。
[8] Lempel, A. and J. Ziv, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, September 1977.
[8]のLempel、A.およびJ. Ziv符号、「逐次データ圧縮用の汎用アルゴリズム」、情報理論、巻に関するIEEEトランザクション。 IT-23、第3号、1977年9月。
Author's Address
著者のアドレス
Robert Friend Hifn 5973 Avenida Encinas Carlsbad, CA 92008 US
ロバート・フレンドHIFN 5973アベニーダEncinasカールスバッド、CA 92008米国
EMail: rfriend@hifn.com
メールアドレス：rfriend@hifn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、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機能のための基金は現在、インターネット協会によって提供されます。