RFC 7918 - Transport Layer Security (TLS) False Start 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7918
タイトル : RFC 7918 - トランスポート層セキュリティ（TLS）False Start
翻訳編集 : 自動生成

[要約] RFC 7918は、Transport Layer Security (TLS) False Startの実装に関する技術的なガイドラインを提供します。この文書の目的は、TLSハンドシェイクの時間を短縮し、より迅速なデータ通信を可能にすることにあります。False Startを利用することで、クライアントはサーバーからの完全なハンドシェイク確認を待たずに、暗号化されたデータの送信を開始できます。これは特に、レイテンシが重要なウェブブラウジングやAPI呼び出しなどのシナリオで有用です。関連するRFCには、TLSプロトコルを定義するRFC 5246（TLS 1.2）や、その後継であるRFC 8446（TLS 1.3）などがあります。

Internet Engineering Task Force (IETF)                        A. Langley
Request for Comments: 7918                                   N. Modadugu
Category: Informational                                       B. Moeller
ISSN: 2070-1721                                                   Google
                                                             August 2016

Transport Layer Security (TLS) False Start

トランスポート層セキュリティ（TLS）False Start

Abstract

概要

This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.

このドキュメントでは、「False Start」と呼ばれるトランスポート層セキュリティ（TLS）クライアント実装のオプションの動作を指定します。これは、プロトコルのタイミングにのみ影響し、ネットワーク上のプロトコルデータには影響せず、一方的に実装できます。 TLS False Startは、ハンドシェイクの待ち時間を1回の往復に減らします。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7918.

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

著作権表示

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 . . . . . . . . . . . . . . . . . . . .   4
   3.  False Start Compatibility . . . . . . . . . . . . . . . . . .   4
   4.  Client-Side False Start . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.1.  Symmetric Cipher  . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Protocol Version  . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Key Exchange and Client Certificate Type  . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Implementation Notes . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246] requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data. Thus, using TLS can add a latency penalty of two network round-trip times for application protocols in which the client sends data first, such as HTTP [RFC7230]. Figure 1 (copied from [RFC5246]) shows the message flow for a full handshake.

TLS 1.2 [RFC5246]までのTLSプロトコルバージョンの完全なハンドシェイクでは、ハンドシェイクが完了し、プロトコルパーティがアプリケーションデータの送信を開始する前に、2つの完全なプロトコルラウンド（4フライト）が必要です。したがって、TLSを使用すると、クライアントが最初にデータを送信するアプリケーションプロトコル（HTTP [RFC7230]など）に対して、ネットワークラウンドトリップ時間2分の遅延ペナルティが追加される可能性があります。図1（[RFC5246]からコピー）は、完全なハンドシェイクのメッセージフローを示しています。

Client Server

クライアントサーバー

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

Figure 1: Message Flow for a Full Handshake

図1：フルハンドシェイクのメッセージフロー

This document describes a technique that alleviates the latency burden imposed by TLS: the client-side TLS False Start. If certain conditions are met, the client can start to send application data when the full handshake is only partially complete, namely, when the client has sent its own ChangeCipherSpec and Finished messages (thus having updated its TLS Record Protocol write state as negotiated in the handshake) but has yet to receive the server's ChangeCipherSpec and Finished messages. (Per Section 7.4.9 of [RFC5246], after a full handshake, the client would have to delay sending application data until it has received and validated the server's Finished message.) Accordingly, the latency penalty for using TLS with HTTP can be kept at one round-trip time.

このドキュメントでは、TLSによって課せられるレイテンシの負担を軽減する手法、つまりクライアント側のTLS False Startについて説明します。特定の条件が満たされている場合、完全なハンドシェイクが部分的にしか完了していないとき、つまり、クライアントが独自のChangeCipherSpecおよび終了メッセージを送信したときに、クライアントはアプリケーションデータの送信を開始できます（したがって、ハンドシェイク）が、サーバーのChangeCipherSpecおよびFinishedメッセージをまだ受信していません。（[RFC5246]のセクション7.4.9に従い、完全なハンドシェイクの後、クライアントはサーバーの完了メッセージを受信して検証するまでアプリケーションデータの送信を遅らせる必要があります。）したがって、HTTPでTLSを使用する場合の遅延ペナルティを維持できます。 1つの往復時間。

Note that in practice, the TCP three-way handshake [RFC0793] typically adds one round-trip time before the client can even send the ClientHello. See [RFC7413] for a latency improvement at that level.

実際には、TCP 3ウェイハンドシェイク[RFC0793]は通常、クライアントがClientHelloを送信する前に1往復の時間を追加することに注意してください。そのレベルでの待ち時間の改善については、[RFC7413]を参照してください。

When an earlier TLS session is resumed, TLS uses an abbreviated handshake with only three protocol flights. For application protocols in which the client sends data first, this abbreviated handshake adds just one round-trip time to begin with, so there is no need for a client-side False Start. However, if the server sends application data first, the abbreviated handshake adds two round-trip times, and this could be reduced to just one added round-trip time by doing a server-side False Start. There is little need for this in practice, so this document does not consider server-side False Starts further.

以前のTLSセッションが再開されると、TLSは3つのプロトコルフライトのみで省略されたハンドシェイクを使用します。クライアントが最初にデータを送信するアプリケーションプロトコルの場合、この簡略化されたハンドシェイクにより、最初に往復時間が1つだけ追加されるため、クライアント側のFalse Startは必要ありません。ただし、サーバーが最初にアプリケーションデータを送信する場合、短縮されたハンドシェイクによって2つの往復時間が追加されます。サーバー側のFalse Startを実行することで、追加の往復時間を1つに減らすことができます。実際にはこれが必要になることはほとんどないため、このドキュメントではサーバー側の誤った開始については考慮していません。

Note also that TLS versions 1.3 [TLS13] and beyond are out of scope for this document. False Start will not be needed with these newer versions since protocol flows minimizing the number of round trips have become a first-order design goal.

TLSバージョン1.3 [TLS13]以降は、このドキュメントの範囲外であることにも注意してください。これらの新しいバージョンでは、ラウンドトリップの数を最小限に抑えるプロトコルフローが一次設計目標となっているため、False Startは必要ありません。

In a False Start, when the client sends application data before it has received and verified the server's Finished message, there are two possible outcomes:

False Startでは、クライアントがサーバーの完了メッセージを受信して検証する前にアプリケーションデータを送信すると、2つの結果が考えられます。

o The handshake completes successfully: The handshake is retroactively validated when both Finished messages have been received and verified. This retroactively validates the handshake. In this case, the transcript of protocol data carried over the transport underlying TLS will look as usual, apart from the different timing.

o ハンドシェイクは正常に完了します。両方の完了メッセージを受信して検証すると、ハンドシェイクは遡及的に検証されます。これにより、ハンドシェイクが遡及的に検証されます。この場合、TLSの基礎となるトランスポートを介して伝送されるプロトコルデータのトランスクリプトは、異なるタイミングを除いて、通常のように見えます。

o The handshake fails: If a party does not receive the other side's Finished message or if the Finished message's contents are not correct, the handshake never gets validated. This means that an attacker may have removed, changed, or injected handshake messages. In this case, data has been sent over the underlying transport that would not have been sent without the False Start.

o ハンドシェイクが失敗する：パーティが相手側の終了メッセージを受信しない場合、または終了メッセージの内容が正しくない場合、ハンドシェイクは検証されません。つまり、攻撃者がハンドシェイクメッセージを削除、変更、または挿入した可能性があります。この場合、データは偽の開始なしでは送信されなかったはずの基になるトランスポートを介して送信されています。

The latter scenario makes it necessary to restrict when a False Start is allowed, as described in this document. Section 3 considers basic requirements for using False Start. Section 4 specifies the behavior for clients, referring to important security considerations in Section 5.

後者のシナリオでは、このドキュメントで説明されているように、False Startが許可されるタイミングを制限する必要があります。セクション3では、False Startを使用するための基本的な要件について検討します。セクション4では、セクション5のセキュリティに関する重要な考慮事項を参照しながら、クライアントの動作を指定します。

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. False Start Compatibility

3. 偽スタートの互換性

TLS False Start as described in detail in the subsequent sections, if implemented, is an optional feature.

TLS False Startは、後続のセクションで詳細に説明されているように、実装されている場合、オプションの機能です。

A TLS server implementation is defined to be "False Start compatible" if it tolerates receiving TLS records on the transport connection early, before the protocol has reached the state to process them. For successful use of client-side False Start in a TLS connection, the server has to be False Start compatible. Out-of-band knowledge that the server is False Start compatible may be available, e.g., if this is mandated by specific application profile standards. As discussed in Appendix A, the requirement for False Start compatibility generally does not pose a hindrance in practice.

プロトコルが状態を処理する前にトランスポート接続でTLSレコードの受信を許容する場合、TLSサーバー実装は「False Start互換」であると定義されています。 TLS接続でクライアント側のFalse Startを正常に使用するには、サーバーがFalse Startに対応している必要があります。サーバーがFalse Startと互換性があるという帯域外の知識は、たとえば、これが特定のアプリケーションプロファイル標準によって義務付けられている場合に利用できる可能性があります。付録Aで説明したように、False Startの互換性の要件は、通常、実際には障害にはなりません。

4. Client-Side False Start

4. クライアント側の偽スタート

This section specifies a change to the behavior of TLS client implementations in full TLS handshakes.

このセクションでは、完全なTLSハンドシェイクでのTLSクライアント実装の動作の変更について説明します。

When the client has sent its ChangeCipherSpec and Finished messages, its default behavior per [RFC5246] is to not send application data until it has received the server's ChangeCipherSpec and Finished messages, which completes the handshake. With the False Start protocol modification, the client MAY send application data earlier (under the new Cipher Spec) if each of the following conditions is satisfied:

クライアントがChangeCipherSpecおよびFinishedメッセージを送信した場合、[RFC5246]のデフォルトの動作では、サーバーのChangeCipherSpecおよびFinishedメッセージを受信してハンドシェイクを完了するまで、アプリケーションデータを送信しません。 False Startプロトコルの変更により、次の各条件が満たされた場合、クライアントは（新しい暗号仕様の下で）アプリケーションデータを以前に送信できます（MAY）。

o The application layer has requested the TLS False Start option.

o アプリケーション層がTLS False Startオプションを要求しました。

o The symmetric cipher defined by the cipher suite negotiated in this handshake has been whitelisted for use with False Start according to the Security Considerations in Section 5.1.

o このハンドシェイクでネゴシエートされた暗号スイートによって定義された対称暗号は、セクション5.1のセキュリティに関する考慮事項に従って、False Startで使用するためにホワイトリストに登録されています。

o The protocol version chosen by ServerHello.server_version has been whitelisted for use with False Start according to the Security Considerations in Section 5.2.

o ServerHello.server_versionによって選択されたプロトコルバージョンは、セクション5.2のセキュリティに関する考慮事項に従って、False Startで使用するためにホワイトリストに登録されています。

o The key exchange method defined by the cipher suite negotiated in this handshake and, if applicable, its parameters have been whitelisted for use with False Start according to the Security Considerations in Section 5.3.

o このハンドシェイクでネゴシエートされた暗号スイートによって定義された鍵交換方法と、該当する場合、そのパラメータは、セクション5.3のセキュリティに関する考慮事項に従って、False Startで使用するためにホワイトリストに登録されています。

o In the case of a handshake with client authentication, the client certificate type has been whitelisted for use with False Start according to the Security Considerations in Section 5.3.

o クライアント認証を伴うハンドシェイクの場合、クライアント証明書タイプは、セクション5.3のセキュリティに関する考慮事項に従って、False Startで使用するためにホワイトリストに登録されています。

The rules for receiving data from the server remain unchanged.

サーバーからデータを受信するためのルールは変更されていません。

Note that the TLS client cannot infer the presence of an authenticated server until all handshake messages have been received. With False Start, unlike with the default handshake behavior, applications are able to send data before this point has been reached: from an application point of view, being able to send data does not imply that an authenticated peer is present. Accordingly, it is recommended that TLS implementations allow the application layer to query whether the handshake has completed.

TLSクライアントは、すべてのハンドシェイクメッセージが受信されるまで、認証済みサーバーの存在を推測できないことに注意してください。 False Startを使用すると、デフォルトのハンドシェイク動作とは異なり、アプリケーションはこのポイントに達する前にデータを送信できます。アプリケーションの観点からは、データを送信できることは、認証されたピアが存在することを意味しません。したがって、TLS実装では、アプリケーション層がハンドシェイクが完了したかどうかを照会できるようにすることをお勧めします。

5. Security Considerations

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

In a TLS handshake, the Finished messages serve to validate the entire handshake. These messages are based on a hash of the handshake so far processed by a Pseudorandom Function (PRF) keyed with the new master secret (serving as a Message Authentication Code (MAC)) and are also sent under the new Cipher Spec with its keyed MAC, where the MAC key again is derived from the master secret. The protocol design relies on the assumption that any server and/or client authentication done during the handshake carries over to this. While an attacker could, for example, have changed the cipher suite list sent by the client to the server and thus influenced cipher suite selection (presumably towards a less secure choice) or could have made other modifications to handshake messages in transmission, the attacker would not be able to round off the modified handshake with a valid Finished message: every TLS cipher suite is presumed to key the PRF appropriately to ensure unforgeability. Verifying the Finished messages validates the handshake and confirms that the handshake has not been tampered with; thus, secure encryption is bootstrapped from secure authentication.

TLSハンドシェイクでは、終了メッセージはハンドシェイク全体を検証するために役立ちます。これらのメッセージは、新しいマスターシークレット（メッセージ認証コード（MAC）として機能）をキーとする疑似ランダム関数（PRF）によってこれまでに処理されたハンドシェイクのハッシュに基づいており、キーをMACとする新しい暗号仕様で送信されます。ここでも、MACキーはマスターシークレットから派生しています。プロトコルの設計は、ハンドシェイク中に行われたサーバーおよび/またはクライアント認証がこれに引き継がれるという前提に依存しています。攻撃者は、たとえば、クライアントからサーバーに送信される暗号スイートリストを変更し、暗号スイートの選択に影響を与える可能性があります（おそらく安全性の低い選択に向けて）、または送信中のハンドシェイクメッセージに他の変更を加える可能性がありますが、変更されたハンドシェイクを有効な終了メッセージで丸めることができない：すべてのTLS暗号スイートは、偽造を確実にするためにPRFを適切にキーイングすると推定されます。完了メッセージを確認すると、ハンドシェイクが検証され、ハンドシェイクが改ざんされていないことが確認されます。したがって、安全な暗号化は安全な認証からブートストラップされます。

Using False Start interferes with this approach of bootstrapping secure encryption from secure authentication, as application data may have already been sent before Finished validation confirms that the handshake has not been tampered with -- so there is generally no way to be sure that communication with the expected peer is indeed taking place during the False Start. Instead, the security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, it must be the legitimate peer. While an attacker could be influencing the handshake (restricting cipher suite selection, modifying key exchange messages, etc.), the attacker should not be able to benefit from this. The TLS protocol already relies on such a security property for authentication; with False Start, the same is needed for encryption. This motivates the rules put forth in the following subsections.

False Startを使用すると、安全な認証から安全な暗号化をブートストラップするこのアプローチに干渉します。完了した検証でハンドシェイクが改ざんされていないことを確認する前にアプリケーションデータがすでに送信されている可能性があるため、通常、予想されるピアは実際、False Start中に発生しています。代わりに、セキュリティ目標は、だれかが偽スタートで送信されたアプリケーションデータを解読できる場合、それが正当なピアでなければならないことを保証することです。攻撃者はハンドシェイクに影響を与える可能性がありますが（暗号スイートの選択の制限、鍵交換メッセージの変更など）、攻撃者はこれから利益を得ることはできません。 TLSプロトコルは認証のためにそのようなセキュリティプロパティに既に依存しています。 False Startでは、暗号化にも同じことが必要です。これにより、次のサブセクションで説明するルールが動機付けられます。

It is prudent for applications to be even more restrictive. If heuristically a small list of cipher suites and a single protocol version is found to be sufficient for the majority of TLS handshakes in practice, it could make sense to forego False Start for any handshake that does not match this expected pattern, even if there is no concrete reason to assume a cryptographic weakness. Similarly, if handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman (ECDH) over one of a few named curves, it could make sense to disallow False Start with any other supported curve.

アプリケーションをさらに制限することは賢明です。ヒューリスティックな方法で暗号スイートの小さなリストと単一のプロトコルバージョンが実際のTLSハンドシェイクの大部分に十分であることが判明した場合、たとえこの予測パターンと一致しないハンドシェイクについても、False Startを無視することは意味があります。暗号の弱点を想定する具体的な理由はありません。同様に、ハンドシェイクがほとんどの場合、いくつかの名前付き曲線のいずれかで一時楕円曲線Diffie-Hellman（ECDH）を使用する場合、サポートされている他の曲線でFalse Startを許可しないことは理にかなっています。

5.1. Symmetric Cipher

5.1. 対称暗号

Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a symmetric cipher that is considered cryptographically strong.

暗号スイートが暗号学的に強力であると見なされる対称暗号を使用しない限り、クライアントはハンドシェイクでFalse Startプロトコルの変更を使用してはなりません（MUST NOT）。

Implementations may have their own classification of ciphers (and may additionally allow the application layer to provide a classification), but generally only symmetric ciphers with an effective key length of 128 bits or more can be considered strong. Also, various ciphers specified for use with TLS are known to have cryptographic weaknesses regardless of key length (none of the ciphers specified in [RFC4492] and [RFC5246] can be recommended for use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 ciphers specified in [RFC5288] and [RFC5289] can be considered sufficiently strong for most uses. Implementations that support additional cipher suites have to be careful to whitelist only suitable symmetric ciphers; if in doubt, False Start should not be used with a given symmetric cipher.

実装には独自の暗号の分類があります（さらに、アプリケーション層が分類を提供できるようにすることもできます）が、通常、有効なキーの長さが128ビット以上の対称暗号のみが強力と見なされます。また、TLSでの使用が指定されたさまざまな暗号には、鍵の長さに関係なく暗号の弱点があることが知られています（[RFC4492]および[RFC5246]で指定された暗号は、False Startでの使用を推奨できません）。 [RFC5288]と[RFC5289]で指定されているAES_128_GCM_SHA256またはAES_256_GCM_SHA384暗号は、ほとんどの用途で十分に強いと見なすことができます。追加の暗号スイートをサポートする実装では、適切な対称暗号のみをホワイトリストに登録するように注意する必要があります。疑わしい場合は、False Startを特定の対称暗号で使用しないでください。

While an attacker can change handshake messages to force a downgrade to a less secure symmetric cipher than otherwise would have been chosen, this rule ensures that in such a downgrade attack, no application data will be sent under an insecure symmetric cipher.

攻撃者はハンドシェイクメッセージを変更して、他の方法よりも安全性の低い対称暗号にダウングレードすることを強制できますが、このルールにより、このようなダウングレード攻撃では、安全でない対称暗号でアプリケーションデータが送信されなくなります。

5.2. Protocol Version

5.2. プロトコルバージョン

Clients MUST NOT use the False Start protocol modification in a handshake unless the protocol version chosen by ServerHello.server_version has been whitelisted for this use.

ServerHello.server_versionによって選択されたプロトコルバージョンがこの用途のためにホワイトリストに登録されていない限り、クライアントはハンドシェイクでFalse Startプロトコルの変更を使用してはなりません（MUST NOT）。

Generally, to avoid potential protocol downgrade attacks, implementations should whitelist only their latest (highest-valued) supported TLS protocol version (and, if applicable, any earlier protocol versions that they would use in fallback retries without TLS_FALLBACK_SCSV [RFC7507]).

一般に、潜在的なプロトコルダウングレード攻撃を回避するために、実装では最新（最高値）のサポートされているTLSプロトコルバージョン（および、該当する場合、TLS_FALLBACK_SCSV [RFC7507]なしのフォールバック再試行で使用する以前のプロトコルバージョン）のみをホワイトリストに登録する必要があります。

The details of nominally identical cipher suites can differ between protocol versions, so this reinforces Section 5.1.

名目上同一の暗号スイートの詳細は、プロトコルバージョン間で異なる可能性があるため、これによりセクション5.1が強化されます。

5.3. Key Exchange and Client Certificate Type

5.3. 鍵交換とクライアント証明書のタイプ

Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a key exchange method that has been whitelisted for this use. Also, clients MUST NOT use the False Start protocol modification unless any parameters to the key exchange methods (such as ServerDHParams or ServerECDHParams) have been whitelisted for this use. Furthermore, when using client authentication, clients MUST NOT use the False Start protocol modification unless the client certificate type has been whitelisted for this use.

暗号スイートがこの使用のためにホワイトリストに登録されている鍵交換方式を使用しない限り、クライアントはハンドシェイクでFalse Startプロトコルの変更を使用してはなりません（MUST NOT）。また、クライアントは、キー交換メソッド（ServerDHParamsやServerECDHParamsなど）のパラメーターがホワイトリストに登録されていない限り、False Startプロトコルの変更を使用してはなりません（MUST NOT）。さらに、クライアント認証を使用する場合、クライアント証明書タイプがこの用途でホワイトリストに登録されていない限り、クライアントはFalse Startプロトコルの変更を使用してはなりません（MUST NOT）。

Implementations may have their own whitelists of key exchange methods, parameters, and client certificate types (and may additionally allow the application layer to specify whitelists). Generally, out of the options from [RFC5246] and [RFC4492], the following whitelists are recommended:

実装には、鍵交換メソッド、パラメーター、およびクライアント証明書タイプの独自のホワイトリストがある場合があります（さらに、アプリケーション層がホワイトリストを指定できるようにする場合もあります）。一般に、[RFC5246]と[RFC4492]のオプションのうち、次のホワイトリストが推奨されます。

o Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA

o 鍵交換方式：DHE_RSA、ECDHE_RSA、DHE_DSS、ECDHE_ECDSA

o Parameters: well-known DH groups (at least 3,072 bits), named curves (at least 256 bits)

o パラメータ：既知のDHグループ（少なくとも3,072ビット）、名前付き曲線（少なくとも256ビット）

o Client certificate types: none

o クライアント証明書タイプ：なし

However, if an implementation that supports only key exchange methods from [RFC5246] and [RFC4492] does not support any of the above key exchange methods, all of its supported key exchange methods can be whitelisted for False Start use. Care is required with any additional key exchange methods, as these may not have similar properties.

ただし、[RFC5246]および[RFC4492]のキー交換メソッドのみをサポートする実装が上記のキー交換メソッドのいずれもサポートしていない場合、サポートされているすべてのキー交換メソッドをFalse Startの使用のためにホワイトリストに登録できます。追加の鍵交換方法には同様の特性がない場合があるため、注意が必要です。

The recommended whitelists are such that if cryptographic algorithms suitable for forward secrecy would possibly be negotiated, no False Start will take place if the current handshake fails to provide forward secrecy. (Forward secrecy can be achieved using ephemeral Diffie-Hellman or ephemeral Elliptic Curve Diffie-Hellman; there is no forward secrecy when using a key exchange method of RSA, RSA_PSK, DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) As usual, the benefits of forward secrecy may need to be balanced against efficiency, and accordingly, even implementations that support the above key exchange methods might whitelist further key exchange methods and client certificate types.

推奨されるホワイトリストは、転送秘密に適した暗号アルゴリズムがネゴシエートされる可能性がある場合、現在のハンドシェイクが転送秘密を提供できなくても、偽スタートは行われません。（フォワード機密性は、エフェメラルDiffie-Hellmanまたはエフェメラル楕円曲線ディフィーヘルマンを使用して達成できます。RSA、RSA_PSK、DH_DSS、DH_RSA、ECDH_ECDSA、またはECDH_RSAのキー交換方式、またはクライアント証明書タイプの使用時にフォワード機密性はありません。 rsa_fixed_dh、dss_fixed_dh、rsa_fixed_ecdh、またはecdsa_fixed_ecdh。）通常どおり、前方秘密性の利点は効率とのバランスを取る必要がある場合があり、したがって、上記の鍵交換方法をサポートする実装でさえ、さらなる鍵交換方法とクライアント証明書タイプをホワイトリストに登録する場合があります。

Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow forward security, but using False Start with any of these means sending application data tied to the client's signature before the server's authenticity (and thus the CertificateRequest message) has been completely verified, so these too are not generally suitable for the client certificate type whitelist.

クライアント証明書タイプrsa_sign、dss_sign、およびecdsa_signは転送セキュリティを許可しますが、これらのいずれかでFalse Startを使用すると、サーバーの信頼性（したがってCertificateRequestメッセージ）が完全に検証される前に、クライアントの署名に関連付けられたアプリケーションデータを送信します。一般に、クライアント証明書タイプのホワイトリストには適していません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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>。

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。

[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>。

[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.

[RFC5288] Salowey、J.、Choudhury、A。、およびD. McGrew、「TLS用のAES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、DOI 10.17487 / RFC5288、2008年8月、<http：// www。 rfc-editor.org/info/rfc5288>。

[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.

[RFC5289] Rescorla、E。、「SHA-256 / 384およびAESガロアカウンターモード（GCM）を使用したTLS楕円曲線暗号スイート」、RFC 5289、DOI 10.17487 / RFC5289、2008年8月、<http：//www.rfc- editor.org/info/rfc5289>。

6.2. Informative References

6.2. 参考引用

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.

[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<http：//www.rfc-editor .org / info / rfc7413>。

[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <http://www.rfc-editor.org/info/rfc7507>.

[RFC7507] Moeller、B。およびA. Langley、「プロトコルダウングレード攻撃を防止するためのTLSフォールバックシグナリング暗号スイート値（SCSV）」、RFC 7507、DOI 10.17487 / RFC7507、2015年4月、<http：//www.rfc-editor .org / info / rfc7507>。

[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-14, July 2016.

[TLS13] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、Work in Progress、draft-ietf-tls-tls13-14、2016年7月。

Appendix A. Implementation Notes

付録A.実装上の注意

TLS False Start is a modification to the TLS protocol, and some implementations that conform to [RFC5246] may have problems interacting with implementations that use the False Start modification. If the peer uses a False Start, application data records may be received directly following the peer's Finished message, before the TLS implementation has sent its own Finished message. False Start compatibility as defined in Section 3 ensures that these records with application data will simply remain buffered for later processing.

TLS False StartはTLSプロトコルの変更であり、[RFC5246]に準拠する一部の実装では、False Start変更を使用する実装との対話に問題がある可能性があります。ピアがFalse Startを使用する場合、TLS実装が独自のFinishedメッセージを送信する前に、ピアのFinishedメッセージの直後にアプリケーションデータレコードが受信されることがあります。セクション3で定義されているFalse Start互換性により、アプリケーションデータを含むこれらのレコードは、後で処理するためにバッファリングされたままになります。

A False Start compatible TLS implementation does not have to be aware of the False Start concept and is certainly not expected to detect whether a False Start handshake is currently taking place: thanks to transport layer buffering, typical implementations will be False Start compatible without having been designed for it.

False Start互換のTLS実装は、False Startの概念を認識する必要はなく、False Startハンドシェイクが現在行われているかどうかを検出することは期待されていません。トランスポート層のバッファリングにより、通常の実装は、False Start互換ではありませんそれのために設計されました。

Acknowledgments

謝辞

The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson, Eric Rescorla, and Brian Smith for their input.

著者は、Wan-Teh Chang、Ben Laurie、Martin Thomson、Eric Rescorla、およびBrian Smithに感謝の意を表します。

Authors' Addresses

著者のアドレス

Adam Langley Google Inc. 345 Spear St San Francisco, CA 94105 United States of America

Adam Langley Google Inc. 345 Spear Stサンフランシスコ、カリフォルニア94105アメリカ合衆国

   Email: agl@google.com

Nagendra Modadugu Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America

Nagendra Modadugu Google Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国

   Email: nagendra@cs.stanford.edu

Bodo Moeller Google Switzerland GmbH Brandschenkestrasse 110 Zurich 8002 Switzerland

ぼどもえっぇｒごおｇぇすぃｔぜｒぁんｄＧｍｂＨＢらんｄｓちぇんけｓｔらっせ１１０ずりｃｈ８００２すぃｔぜｒぁんｄ

   Email: bmoeller@acm.org