[要約] RFC 3943は、Transport Layer Security (TLS) プロトコルでのデータ圧縮にLempel-Ziv-Stac (LZS) アルゴリズムを使用する方法について説明しています。この文書の目的は、TLS通信のデータ量を減少させることにより、ネットワークの帯域幅を節約し、パフォーマンスを向上させることです。LZS圧縮は、特に帯域幅が限られている環境や、大量のデータ転送が必要な場面で有用です。関連するRFCには、TLSプロトコルを定義するRFC 5246や、他の圧縮方法を提案するRFCが含まれますが、RFC 3943は特にLZS圧縮に焦点を当てています。
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)
Lempel-Ziv-Stac (LZS) を使用したトランスポート層セキュリティ (TLS) プロトコル圧縮
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.
Transport Layer Security (TLS) プロトコル (RFC 2246) には、TLS ハンドシェイク プロトコルの一部として可逆データ圧縮方式の選択をネゴシエートし、選択された方式に関連付けられたアルゴリズムを TLS レコード プロトコルの一部として適用する機能が含まれています。TLS は、記録プロトコルを介して交換されるデータが圧縮されないことを指定する 1 つの標準圧縮方法を定義します。このドキュメントでは、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.
Transport Layer Security (TLS) プロトコル (RFC 2246、[2]) には、TLS ハンドシェイク プロトコルの一部として可逆データ圧縮方式の選択をネゴシエートし、選択された方式に関連付けられたアルゴリズムを TLS の一部として適用する機能が含まれています。記録プロトコル。TLS は、標準圧縮方式の 1 つである 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) 接続として使用されることが増えています。圧縮サービスは長い間 IPSec および PPTP VPN 接続に関連付けられてきたため、圧縮サービスを TLS VPN 接続に拡張することで、あらゆる VPN 接続のユーザー エクスペリエンスが維持されます。TLS 内の圧縮は、TLS が提供するセキュリティ サービスを維持しながら、大量のデータの交換に伴う帯域幅と遅延の要件を軽減する 1 つの方法です。
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 で使用する可逆データ圧縮アルゴリズムに関連する追加の圧縮方法について説明します。この文書では、可逆圧縮アルゴリズムである Lempel-Ziv-Stac (LZS) 圧縮の TLS レコード ペイロードへの適用を指定します。この仕様は、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].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。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 [2] のセクション 6 で説明されているように、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 [2] のセクション 6.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 は 16 ビットのインデックスであり、RFC 2246 [2] および RFC 3749 [3] で説明されているようにネゴシエートされます。LZS CompressionMethod は、RFC 2246 [2] で説明されているように、TLS レコード層接続状態に保存されます。
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 セッションごとに個別の圧縮履歴を使用しなければなりません (MUST)。これは 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.
LZ1 [8] と同様のスライディング ウィンドウ圧縮履歴から始まり、LZS として識別される新しい強化された圧縮アルゴリズムが開発されました。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 が使用される場合、圧縮履歴情報が維持され、活用されてもよい (MAY)。
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 圧縮履歴が存在しなければなりません (MUST)。これにより、セキュリティが強化される (共有圧縮履歴によるセッション間での情報漏洩がなくなる) だけでなく、圧縮を使用したすべてのオープン 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 レコードを圧縮する前に、圧縮履歴をリセットしなければなりません (MUST)。送信者にとって、TLS セッション中に処理される後続のすべてのレコードの圧縮履歴を維持することは有利です。これにより、特定のデータ セットの圧縮率が最大になります。いずれの場合も、TLS セッション間のプライバシーを確保するために、この圧縮履歴を他のオープン TLS セッションに使用してはなりません (MUST NOT)。
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 圧縮履歴に関連付けられたメモリ リソースを破棄する必要があります (SHOULD)。つまり、圧縮履歴は、TLS 鍵素材として扱われる必要があります (SHOULD)。
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 ビット Flags TLSComp フィールドの形式は次のとおりです。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | Res | Res | Res | Res | Res | RST | C/U |
+-----+-----+-----+-----+-----+-----+-----+-----+
Res-Reserved
予約済み
Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node.
将来の使用のために予約されています。ゼロに設定する必要があります。受信ノードは無視しなければなりません (MUST)。
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 セッションの最初の圧縮 TLS 送信レコードについては、このビットを値「1」に設定しなければなりません (MUST)。このビットは、圧縮履歴をリセットする必要がある場合の他の例外ケースでも送信機によって使用される場合があります。
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>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<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
<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 ...
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 レコードはいつでも送信できます (MAY)。圧縮によってデータ圧縮 TLS レコード サイズが RFC 2246 のセクション 6.2.2 で定義されている MTU を超えるほど十分に拡張される場合、非圧縮 TLS レコードを送信しなければなりません (MUST)。 圧縮操作の出力は、TLSCompressed 構造体のフラグメント フィールドに配置されます (TLSCompressed)。断片）。
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 レコードを解凍する前に、受信者は解凍履歴をリセットしなければなりません (MUST)。後続のレコードは受信した順序で解凍されます。受信機は、上記のセクション 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 に従って解凍されなければなりません (MUST)。
If the C/U bit is set to "0", the specified decompression history MUST be updated with the received uncompressed data.
C/U ビットが「0」に設定されている場合、指定された解凍履歴を受信した非圧縮データで更新しなければなりません (MUST)。
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 レコードを解凍する前に、受信解凍履歴を初期状態にリセットしてもよい(MAY)。（ただし、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 番目のオプションが推奨されるオプションであり、実装する必要があります (SHOULD)。
There is a third option:
3 番目のオプションがあります。
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 [3] のセクション 2 では、IANA によって維持され、3 つのゾーン内で割り当てられる圧縮方式識別子のレジストリについて説明しています。
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].
IANA は、RFC 3749 [3] のセクション 2 および 5 で説明されているように、RFC 2434 の要求仕様 IANA プールから LZS 圧縮方式の識別子を割り当てました。
The IANA-assigned compression method identifier for LZS is 64 decimal (0x40).
IANA が割り当てた LZS の圧縮方式識別子は、10 進数 64 (0x40) です。
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.
ただし、圧縮と暗号化を組み合わせると、圧縮しなければ公開されなかった情報が公開される場合があります。圧縮前は同じ長さのデータでも、圧縮後は長さが異なる可能性があるため、圧縮データの長さを監視する攻撃者は、対応する非圧縮データに関する情報を導き出すことができる可能性があります。一部の対称暗号化暗号スイートは、対称暗号化データの長さをまったく隠蔽しません。完全にではなく、ある程度隠している人もいます。たとえば、パディングなしでストリーム暗号化を使用する暗号スイートは長さをまったく隠しません。パディングを伴う Cipher Block Chaining (CBC) 暗号化を使用する暗号スイートは、パディング量の選択方法に応じて、ある程度の長さの隠蔽を提供します。TLS 圧縮を使用する場合は、圧縮されたデータの長さによって、元の非圧縮データの長さよりも多くの情報が漏洩する可能性があることを考慮する必要があります (SHOULD)。
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.
注意すべきもう 1 つのセキュリティ問題は、LZS 圧縮履歴に平文が含まれていることです。システム外へのあらゆる種類の情報漏洩を防ぐために、圧縮を伴う TLS セッションが終了するとき、実装は圧縮履歴を平文と同様に扱う必要があります (SHOULD)。つまり、圧縮履歴がいかなる形式であっても漏洩しないように注意する必要があります。または再度使用することもできます。これについては、上記のセクション 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] から派生したものです。著者は、Scott Hollenbeck、Douglas Whiting、Russell Dietz の貢献と、Steve Bellovin、Russ Housley、および Eric Rescorla の協力に感謝します。
[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] Hollenbeck, S. "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[3] Hollenbeck, S.「トランスポート層セキュリティ プロトコルの圧縮方法」、RFC 3749、2004 年 5 月。
[4] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[4] Friend、R. および R. Monsour、「LZS を使用した IP ペイロード圧縮」、RFC 2395、1998 年 12 月。
[5] Friend, R. and W. Simpson, "PPP Stac LZS Compression Protocol", RFC 1974, August 1996.
[5] Friend、R. および W. Simpson、「PPP Stac LZS Compression Protocol」、RFC 1974、1996 年 8 月。
[6] Schneider, K. and R. Friend, "PPP LZS-DCP Compression Protocol (LZS-DCP)", RFC 1967, August 1996.
[6] Schneider, K. および R. Friend、「PPP LZS-DCP Compression Protocol (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] American National Standards Institute, Inc.、「情報システムのためのデータ圧縮方法」、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 Transactions On Information Theory、Vol.IT-23、第 3 号、1977 年 9 月。
Author's Address
著者の連絡先
Robert Friend Hifn 5973 Avenida Encinas Carlsbad, CA 92008 US
Robert Friend Hifn 5973 Avenida Encinas Carlsbad, CA 92008 US
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (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 エディター機能の資金は現在、インターネット協会によって提供されています。