RFC 7685 - A Transport Layer Security (TLS) ClientHello Padding Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7685
タイトル : RFC 7685 - トランスポート層セキュリティ（TLS）ClientHelloパディング拡張機能
翻訳編集 : 自動生成

[要約] RFC 7685は、Transport Layer Security (TLS) プロトコルにおけるClientHelloメッセージのパディング拡張機能について定義しています。この拡張機能の主な目的は、プライバシー保護とセキュリティの強化です。具体的には、ClientHelloメッセージのサイズを増やすことで、ネットワーク上でのトラフィック分析攻撃をより困難にします。この拡張は、TLSプロトコルを使用するすべてのアプリケーションに適用可能で、特に監視を避けたい場面で有用です。関連するRFCには、TLSプロトコルを定義するRFC 5246 (TLS 1.2) や、その後継であるRFC 8446 (TLS 1.3) などがあります。

Internet Engineering Task Force (IETF)                        A. Langley
Request for Comments: 7685                                    Google Inc
Updates: 5246                                               October 2015
Category: Standards Track
ISSN: 2070-1721

A Transport Layer Security (TLS) ClientHello Padding Extension

トランスポート層セキュリティ（TLS）ClientHelloパディング拡張機能

Abstract

概要

This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.

このメモは、ClientHelloメッセージを目的のサイズに埋め込むために使用できるトランスポート層セキュリティ（TLS）拡張について説明しています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7685.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7685で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   3.  Padding Extension . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Example Usage . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1. Introduction

1. はじめに

Successive TLS [RFC5246] versions have added support for more cipher suites and, over time, more TLS extensions have been defined. This has caused the size of the TLS ClientHello to grow, and the additional size has caused some implementation bugs to come to light. At least one of these implementation bugs can be ameliorated by making the ClientHello even larger. This is desirable given that fully comprehensive patching of affected implementations is difficult to achieve.

連続するTLS [RFC5246]バージョンでは、より多くの暗号スイートのサポートが追加され、時間の経過とともに、より多くのTLS拡張が定義されました。これにより、TLS ClientHelloのサイズが大きくなり、追加のサイズにより、いくつかの実装バグが明らかになりました。これらの実装バグの少なくとも1つは、ClientHelloをさらに大きくすることで改善できます。影響を受ける実装の完全に包括的なパッチを適用することは難しいため、これは望ましいことです。

This memo describes a TLS extension that can be used to pad a ClientHello to a desired size in order to avoid implementation bugs caused by certain ClientHello sizes.

このメモは、特定のClientHelloサイズによって引き起こされる実装のバグを回避するために、ClientHelloを目的のサイズに埋め込むために使用できるTLS拡張について説明しています。

2. Requirements Notation

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Padding Extension

3. パディング拡張

A new extension type ("padding(21)") is defined and MAY be included by the client in its ClientHello message.

新しい拡張タイプ（ "padding（21）"）が定義され、クライアントによってClientHelloメッセージに含まれる場合があります。

   enum {
       padding(21), (65535)
   } ExtensionType;

The "extension_data" for the extension consists of an arbitrary number of zero bytes. For example, the smallest "padding" extension is four bytes long and is encoded as 0x00 0x15 0x00 0x00. A ten-byte extension would include six bytes of "extension_data" and would be encoded as:

拡張の「extension_data」は、任意の数のゼロバイトで構成されます。たとえば、最小の「パディング」拡張は4バイト長で、0x00 0x15 0x00 0x00としてエンコードされます。 10バイトの拡張には6バイトの「extension_data」が含まれ、次のようにエンコードされます。

   00 15 00 06 00 00 00 00 00 00
   |---| |---| |---------------|
     |     |           |
     |     |           \- extension_data: 6 zero bytes
     |     |
     |     \------------- 16-bit, extension_data length
     |
     \------------------- extension_type for padding extension

The client MUST fill the padding extension completely with zero bytes, although the padding extension_data field may be empty.

クライアントは、パディングextension_dataフィールドが空の場合がありますが、パディング拡張をゼロバイトで完全に埋める必要があります。

The server MUST NOT echo the extension.

サーバーは拡張機能をエコーしてはいけません。

4. Example Usage

4. 使用例

As an example, consider a client that wishes to avoid sending a ClientHello with a TLSCiphertext.length between 256 and 511 bytes (inclusive). This case is considered because at least one TLS implementation is known to hang the connection when such a ClientHello record is received.

例として、TLSCiphertext.lengthが256〜511バイト（両端を含む）のClientHelloを送信しないようにするクライアントを考えてみます。このようなClientHelloレコードを受信すると、少なくとも1つのTLS実装が接続をハングすることがわかっているため、このケースが考慮されます。

After building a ClientHello as normal, the client can add four bytes to the length (to account for the "msg_type" and "length" fields of the handshake protocol) and test whether the resulting length falls into that range. If it does, a padding extension can be added in order to push the length to (at least) 512 bytes.

通常どおりにClientHelloを構築した後、クライアントは長さに4バイトを追加し（ハンドシェイクプロトコルの「msg_type」および「length」フィールドを考慮するため）、結果の長さがその範囲にあるかどうかをテストできます。その場合、長さを（少なくとも）512バイトにプッシュするために、パディング拡張機能を追加できます。

Note that if the original ClientHello size was between 505 and 507 bytes, then, with the handshake protocol overhead, the record payload would be between 509 and 511 bytes long. Since it's not possible for an extension to take less than four bytes of space, the additional padding would have to expand the ClientHello record payload beyond 512 bytes in these cases.

元のClientHelloサイズが505〜507バイトの場合、ハンドシェイクプロトコルのオーバーヘッドにより、レコードペイロードは509〜511バイトの長さになることに注意してください。拡張が4バイト未満のスペースを取ることは不可能であるため、追加のパディングは、これらの場合、512バイトを超えてClientHelloレコードのペイロードを拡張する必要があります。

5. Security Considerations

5. セキュリティに関する考慮事項

The contents of the padding extension could be used as a covert channel. In order to prevent this, the contents are required to be all zeros, although the length of the extension can still be used as a much smaller covert channel.

パディング拡張の内容は、隠れチャネルとして使用できます。これを防ぐには、内容をすべて0にする必要がありますが、拡張の長さは、はるかに小さな隠れチャネルとして使用できます。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has permanently registered value 21 (padding) in the "ExtensionType Values" registry.

IANAは、 "ExtensionType値"レジストリに永続的に値21（パディング）を登録しています。

7. Normative References

7. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

Acknowledgements

謝辞

The author gratefully acknowledges the contributions of Wan-Teh Chang and the suggestions of Eric Rescorla.

著者は、Wan-Teh Changの貢献とEric Rescorlaの提案に感謝します。

Author's Address

著者のアドレス

Adam Langley Google Inc

アダムラングレーGoogle Inc

   Email: agl@google.com