RFC 7507 - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7507
タイトル : RFC 7507 - プロトコルダウングレード攻撃を防止するためのTLSフォールバックシグナリング暗号スイート値（SCSV）
翻訳編集 : 自動生成

[要約] RFC 7507は、TLSプロトコルにおけるプロトコルダウングレード攻撃を防ぐためのメカニズムを定義しています。このRFCは、TLS Fallback Signaling Cipher Suite Value (SCSV)という特別なシグナルを使用して、クライアントが意図的にプロトコルバージョンを下げている場合のみ、サーバーがそれを許可するようにします。これにより、攻撃者が通信をより弱いプロトコルバージョンに強制的にダウングレードさせることを防ぎます。関連するRFCとしては、TLSプロトコルを定義するRFC 5246 (TLS 1.2) やその後継のRFC 8446 (TLS 1.3) などがあります。RFC 7507は、特にネットワークセキュリティに関心のある開発者やシステム管理者にとって重要です。

Internet Engineering Task Force (IETF)                        B. Moeller
Request for Comments: 7507                                    A. Langley
Updates: 2246, 4346, 4347, 5246, 6347                             Google
Category: Standards Track                                     April 2015
ISSN: 2070-1721

TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks

プロトコルダウングレード攻撃を防止するためのTLSフォールバックシグナリング暗号スイート値（SCSV）

Abstract

概要

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

このドキュメントでは、トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）プロトコルに対するプロトコルダウングレード攻撃を防止するシグナリング暗号スイート値（SCSV）を定義します。 RFC 2246、4346、4347、5246、および6347を更新します。サーバーの更新に関する考慮事項も含まれています。

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/rfc7507.

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

著作権表示

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.  Protocol Values . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

To work around interoperability problems with legacy servers, many TLS client implementations do not rely on the TLS protocol version negotiation mechanism alone but will intentionally reconnect using a downgraded protocol if initial handshake attempts fail. Such clients may fall back to connections in which they announce a version as low as TLS 1.0 (or even its predecessor, Secure Socket Layer (SSL) 3.0) as the highest supported version.

レガシーサーバーとの相互運用性の問題を回避するために、多くのTLSクライアント実装はTLSプロトコルバージョンネゴシエーションメカニズムのみに依存せず、最初のハンドシェイク試行が失敗した場合、ダウングレードされたプロトコルを使用して意図的に再接続します。そのようなクライアントは、サポートされている最も高いバージョンとしてTLS 1.0（またはその前身であるSecure Socket Layer（SSL）3.0）の低いバージョンを発表する接続にフォールバックする場合があります。

While such fallback retries can be a useful last resort for connections to actual legacy servers, there's a risk that active attackers could exploit the downgrade strategy to weaken the cryptographic security of connections. Also, handshake errors due to network glitches could similarly be misinterpreted as interaction with a legacy server and result in a protocol downgrade.

このようなフォールバックの再試行は、実際のレガシーサーバーへの接続の最後の手段として役立ちますが、アクティブな攻撃者がダウングレード戦略を悪用して、接続の暗号化セキュリティを弱める可能性があります。また、ネットワークの不具合によるハンドシェイクエラーも同様に、レガシーサーバーとのやり取りとして誤って解釈され、プロトコルのダウングレードを引き起こす可能性があります。

All unnecessary protocol downgrades are undesirable (e.g., from TLS 1.2 to TLS 1.1, if both the client and the server actually do support TLS 1.2); they can be particularly harmful when the result is loss of the TLS extension feature by downgrading to SSL 3.0. This document defines an SCSV that can be employed to prevent unintended protocol downgrades between clients and servers that comply with this document by having the client indicate that the current connection attempt is merely a fallback and by having the server return a fatal alert if it detects an inappropriate fallback. (The alert does not necessarily indicate an intentional downgrade attack, since network glitches too could result in inappropriate fallback retries.) The fallback SCSV defined in this document is not a suitable substitute for proper TLS version negotiation. TLS implementations need to properly handle TLS version negotiation and extensibility mechanisms to avoid the security issues and connection delays associated with fallback retries.

すべての不要なプロトコルダウングレードは望ましくありません（たとえば、クライアントとサーバーの両方が実際にTLS 1.2をサポートしている場合、TLS 1.2からTLS 1.1へ）。その結果、SSL 3.0にダウングレードしてTLS拡張機能が失われる場合、特に有害になる可能性があります。このドキュメントは、現在の接続試行がフォールバックにすぎないことをクライアントに示し、サーバーが検出した場合に致命的なアラートを返すことにより、このドキュメントに準拠するクライアントとサーバー間の意図しないプロトコルダウングレードを防ぐために使用できるSCSVを定義します不適切なフォールバック。（ネットワークグリッチも不適切なフォールバックの再試行につながる可能性があるため、アラートは必ずしも意図的なダウングレード攻撃を示しているわけではありません。）このドキュメントで定義されているフォールバックSCSVは、適切なTLSバージョンネゴシエーションの適切な代用ではありません。 TLS実装では、TLSバージョンネゴシエーションと拡張メカニズムを適切に処理して、フォールバックの再試行に関連するセキュリティの問題と接続の遅延を回避する必要があります。

This specification applies to implementations of TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly relevant if the TLS implementations also include support for predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly to later protocol versions.

この仕様は、TLS 1.0 [RFC2246]、TLS 1.1 [RFC4346]、TLS 1.2 [RFC5246]の実装、およびDTLS 1.0 [RFC4347]とDTLS 1.2 [RFC6347]の実装に適用されます。（TLS実装に先行プロトコルSSL 3.0 [RFC6101]のサポートも含まれている場合は特に関連があります。）これは、以降のプロトコルバージョンにも同様に適用できます。

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

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

2. Protocol Values

2. プロトコル値

This document defines a new TLS cipher suite value:

このドキュメントでは、新しいTLS暗号スイートの値を定義しています。

TLS_FALLBACK_SCSV {0x56, 0x00}

TLS_FALLBACK_SCSV {0x56、0x00}

This is an SCSV, i.e., it does not actually correspond to a suite of cryptosystems, and it can never be selected by the server in the handshake; rather, its presence in the Client Hello message serves as a backwards-compatible signal from the client to the server.

これはSCSVです。つまり、実際には一連の暗号システムに対応しておらず、ハンドシェイクでサーバーが選択することはできません。むしろ、Client Helloメッセージ内のその存在は、クライアントからサーバーへの下位互換性のある信号として機能します。

This document also allocates a new alert value in the TLS Alert Registry [RFC5246]:

このドキュメントはまた、TLS Alert Registry [RFC5246]に新しいアラート値を割り当てます。

        enum {
          /* ... */
          inappropriate_fallback(86),
          /* ... */
          (255)
        } AlertDescription;

This alert is only generated by servers, as described in Section 3. It is always fatal.

このアラートは、セクション3で説明されているように、サーバーによってのみ生成されます。常に致命的です。

3. Server Behavior

3. サーバーの動作

This section specifies server behavior when receiving the TLS_FALLBACK_SCSV cipher suite from a client in ClientHello.cipher_suites.

このセクションでは、ClientHello.cipher_suitesのクライアントからTLS_FALLBACK_SCSV暗号スイートを受信したときのサーバーの動作を指定します。

o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, the server MUST respond with a fatal inappropriate_fallback alert (unless it responds with a fatal protocol_version alert because the version indicated in ClientHello.client_version is unsupported). The record layer version number for this alert MUST be set to either ClientHello.client_version (as it would for the Server Hello message if the server was continuing the handshake) or to the record layer version number used by the client.

o TLS_FALLBACK_SCSVがClientHello.cipher_suitesに表示され、サーバーがサポートする最高のプロトコルバージョンがClientHello.client_versionで示されるバージョンよりも高い場合、サーバーは致命的な不適切なフォールバックアラートで応答する必要があります（ただし、 ClientHello.client_versionはサポートされていません）。このアラートのレコードレイヤーバージョン番号は、ClientHello.client_version（サーバーがハンドシェイクを継続している場合のサーバーHelloメッセージの場合と同様）またはクライアントが使用するレコードレイヤーバージョン番号に設定する必要があります。

o Otherwise (either TLS_FALLBACK_SCSV does not appear or it appears and the client's protocol version is at least the highest protocol version supported by the server), the server proceeds with the handshake as usual.

o それ以外の場合（TLS_FALLBACK_SCSVが表示されないか、表示され、クライアントのプロトコルバージョンが少なくともサーバーでサポートされている最も高いプロトコルバージョンである）、サーバーは通常どおりハンドシェイクを続行します。

(A protocol version is supported by the server if, in response to appropriate Client Hello messages, the server would use it for ServerHello.server_version. If a particular protocol version is implemented but completely disabled by server settings, it is not considered supported. For example, if the implementation's highest protocol version is TLS 1.2 but the server operator has disabled this version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not warrant responding with an inappropriate_fallback alert.)

（プロトコルバージョンは、適切なClient Helloメッセージに応答して、サーバーがそれをServerHello.server_versionに使用する場合にサーバーによってサポートされます。特定のプロトコルバージョンが実装されているが、サーバー設定によって完全に無効になっている場合、サポートされているとは見なされません。たとえば、実装の最も高いプロトコルバージョンがTLS 1.2であるにもかかわらず、サーバーオペレーターがこのバージョンを無効にした場合、TLS_FALLBACK_SCSVを使用したTLS 1.1 Client Helloは不適切なフォールバックアラートでの応答を保証しません。）

4. Client Behavior

4. クライアントの動作

The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients that repeat a connection attempt with a downgraded protocol (perform a "fallback retry") in order to work around interoperability problems with legacy servers.

TLS_FALLBACK_SCSV暗号スイートの値は、レガシーサーバーとの相互運用性の問題を回避するために、ダウングレードされたプロトコルで接続試行を繰り返す（「フォールバックリトライ」を実行する）クライアントが使用するためのものです。

o If a client sends a ClientHello.client_version containing a lower value than the latest (highest-valued) version supported by the client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_suites; see Section 6 for security considerations for this recommendation. (The client SHOULD put TLS_FALLBACK_SCSV after all cipher suites that it actually intends to negotiate.)

o クライアントが、クライアントがサポートする最新（最大値）バージョンよりも小さい値を含むClientHello.client_versionを送信する場合、ClientHello.cipher_suitesにTLS_FALLBACK_SCSV暗号スイート値を含める必要があります（SHOULD）。この推奨事項のセキュリティに関する考慮事項については、セクション6を参照してください。（クライアントは、実際にネゴシエートする予定のすべての暗号スイートの後にTLS_FALLBACK_SCSVを置く必要があります。）

o As an exception to the above, when a client intends to resume a session and sets ClientHello.client_version to the protocol version negotiated for that session, it MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it is assumed that the client already knows the highest protocol version supported by the server: see Appendix E.1 of [RFC5246].)

o 上記の例外として、クライアントがセッションを再開する予定で、ClientHello.client_versionをそのセッション用にネゴシエートされたプロトコルバージョンに設定する場合、ClientHello.cipher_suitesにTLS_FALLBACK_SCSVを含めてはなりません（MUST NOT）。（この場合、クライアントはサーバーでサポートされている最も高いプロトコルバージョンをすでに知っていると想定されます。[RFC5246]の付録E.1をご覧ください）。

o If a client sets ClientHello.client_version to its highest supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites.

o クライアントがClientHello.client_versionをサポートされる最高のプロトコルバージョンに設定する場合、ClientHello.cipher_suitesにTLS_FALLBACK_SCSVを含めてはなりません（MUST NOT）。

(A protocol version is supported by the client if the client normally attempts to use it in handshakes. If a particular protocol version is implemented but completely disabled by client settings, it is not considered supported. For example, if the implementation's highest protocol version is TLS 1.2 but the user has disabled this version, a TLS 1.1 handshake is expected and does not warrant sending TLS_FALLBACK_SCSV.)

（クライアントが通常、ハンドシェイクで使用しようとする場合、プロトコルバージョンはクライアントによってサポートされます。特定のプロトコルバージョンが実装されているが、クライアント設定によって完全に無効になっている場合、サポートされているとは見なされません。たとえば、実装の最高のプロトコルバージョンがTLS 1.2ですが、ユーザーがこのバージョンを無効にしています。TLS1.1ハンドシェイクが想定されており、TLS_FALLBACK_SCSVの送信は保証されません。）

Fallback retries could be caused by events such as network glitches, and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an inappropriate_fallback alert in response, indicating that the server supports a higher protocol version. Thus, if a client intends to use retries to work around network glitches, it should then retry with the highest version it supports.

フォールバックの再試行は、ネットワークの不具合などのイベントによって引き起こされる可能性があり、ClientHello.cipher_suitesにTLS_FALLBACK_SCSVを含むクライアントは、サーバーがより高いプロトコルバージョンをサポートしていることを示す応答として不適切なフォールバックアラートを受信する場合があります。したがって、クライアントが再試行を使用してネットワークの不具合を回避しようとする場合は、サポートしている最も高いバージョンで再試行する必要があります。

If a client keeps track of the highest protocol version apparently supported by a particular server for use in ClientHello.client_version later, then if the client receives an inappropriate_fallback alert from that server, it MUST clear the memorized highest supported protocol version. (Without the alert, it is a good idea -- but outside of the scope of this document -- for clients to clear that state after a timeout since the server's highest protocol version could change over time.)

クライアントが、特定のサーバーで明らかにサポートされている最高のプロトコルバージョンを追跡し、後でClientHello.client_versionで使用する場合、クライアントがそのサーバーから不適切なフォールバックアラートを受信した場合、記憶されている最高のサポートされているプロトコルバージョンをクリアする必要があります。（アラートがなければ、サーバーの最高のプロトコルバージョンが時間とともに変化する可能性があるため、タイムアウト後にクライアントがその状態をクリアすることは良い考えですが、このドキュメントの範囲外です。）

For clients that use client-side TLS False Start [false-start], it is important to note that the TLS_FALLBACK_SCSV mechanism cannot protect the first round of application data sent by the client: refer to the Security Considerations (Section 6) of [false-start].

クライアント側のTLS False Start [false-start]を使用するクライアントの場合、TLS_FALLBACK_SCSVメカニズムがクライアントから送信されたアプリケーションデータの最初のラウンドを保護できないことに注意することが重要です。[falseのセキュリティに関する考慮事項（セクション6）を参照] -開始]。

5. Operational Considerations

5. 運用上の考慮事項

Updating legacy server clusters to simultaneously add support for newer protocol versions and support for TLS_FALLBACK_SCSV can have complications if the legacy server implementation is not "version-tolerant" (cannot properly handle Client Hello messages for newer protocol versions): fallback retries required for interoperability with old server nodes might be rejected by updated server nodes.

レガシーサーバークラスターを更新して、新しいプロトコルバージョンのサポートとTLS_FALLBACK_SCSVのサポートを同時に追加すると、レガシーサーバーの実装が「バージョントレラント」でない場合（新しいプロトコルバージョンのClient Helloメッセージを適切に処理できない場合）、複雑になる可能性があります。古いサーバーノードは、更新されたサーバーノードによって拒否される場合があります。

Updating the server cluster in two consecutive steps makes this safe: first, update the server software but leave the highest supported version unchanged (by disabling newer versions in server settings); then, after all legacy (version-intolerant) implementations have been removed, change server settings to allow new protocol versions.

2つの連続するステップでサーバークラスターを更新すると、これが安全になります。まず、サーバーソフトウェアを更新しますが、サポートされている最も高いバージョンは変更しません（サーバー設定で新しいバージョンを無効にすることにより）。次に、すべてのレガシー（バージョン非許容）実装が削除されたら、新しいプロトコルバージョンを許可するようにサーバー設定を変更します。

6. Security Considerations

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

Section 4 does not require client implementations to send TLS_FALLBACK_SCSV in any particular case, it merely recommends it; behavior can be adapted according to the client's security needs. It is important to remember that omitting TLS_FALLBACK_SCSV enables downgrade attacks, so implementors must take into account whether the protocol version given by ClientHello.client_version still provides an acceptable level of protection. For example, during the initial deployment of a new protocol version (when some interoperability problems may have to be expected), smoothly falling back to the previous protocol version in case of problems may be preferable to potentially not being able to connect at all: so TLS_FALLBACK_SCSV could be omitted for this particular protocol downgrade step.

セクション4では、特定の場合にクライアント実装がTLS_FALLBACK_SCSVを送信する必要はなく、単に推奨されます。動作はクライアントのセキュリティニーズに応じて調整できます。 TLS_FALLBACK_SCSVを省略するとダウングレード攻撃が可能になるため、実装者はClientHello.client_versionで指定されたプロトコルバージョンが許容できるレベルの保護を提供しているかどうかを考慮する必要があります。たとえば、新しいプロトコルバージョンの初期展開時（相互運用性の問題が予想される場合）、問題が発生した場合に以前のプロトコルバージョンにスムーズにフォールバックする方が、まったく接続できない可能性よりも好ましい場合があります。この特定のプロトコルダウングレード手順では、TLS_FALLBACK_SCSVを省略できます。

However, it is strongly recommended to send TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the Cipher Block Chaining (CBC) cipher suites in SSL 3.0 have weaknesses that cannot be addressed by implementation workarounds like the remaining weaknesses in later (TLS) protocol versions.

ただし、SSL 3.0にダウングレードするときは、TLS 3.0のダウングレード時にTLS_FALLBACK_SCSVを送信することを強くお勧めします。SSL3.0の暗号化ブロックチェーン（CBC）暗号スイートには、後の（TLS）プロトコルバージョンの残りの弱点のような実装の回避策では対応できない弱点があるためです。

7. IANA Considerations

7. IANAに関する考慮事項

IANA has added TLS cipher suite number 0x56,0x00 with the name TLS_FALLBACK_SCSV to the TLS Cipher Suite Registry and alert number 86 with the name inappropriate_fallback to the TLS Alert Registry, as shown below. The registries are available from <http://www.iana.org/assignments/tls-parameters>.

IANAは、以下に示すように、TLS暗号スイートレジストリに名前TLS_FALLBACK_SCSVのTLS暗号スイート番号0x56,0x00を追加し、TLSアラートレジストリに不適切な名前のアラート番号86を追加しました。レジストリは、<http://www.iana.org/assignments/tls-parameters>から入手できます。

          +-----------+-------------------+---------+-----------+
          |   Value   |    Description    | DTLS-OK | Reference |
          +-----------+-------------------+---------+-----------+
          | 0x56,0x00 | TLS_FALLBACK_SCSV |    Y    |  RFC 7507 |
          +-----------+-------------------+---------+-----------+

Addition to the TLS Cipher Suite Registry

TLS暗号スイートレジストリへの追加

         +-------+------------------------+---------+-----------+
         | Value |      Description       | DTLS-OK | Reference |
         +-------+------------------------+---------+-----------+
         |   86  | inappropriate_fallback |    Y    |  RFC 7507 |
         +-------+------------------------+---------+-----------+

Addition to the TLS Alert Registry

TLS Alert Registryへの追加

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

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

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

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月、<http://www.rfc-editor.org/info/rfc2246>。

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.

[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月、<http://www.rfc-editor.org/info/rfc4346>。

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006, <http://www.rfc-editor.org/info/rfc4347>.

[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月、<http://www.rfc-editor.org/info/rfc4347>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 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、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。

8.2. Informative References

8.2. 参考引用

[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.

[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、2011年8月、<http://www.rfc-editor.org/ info / rfc6101>。

[false-start] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-bmoeller-tls-falsestart-01, November 2014.

[false-start] Langley、A.、Modadugu、N。、およびB. Moeller、「Transport Layer Security（TLS）False Start」、Work in Progress、draft-bmoeller-tls-falsestart-01、2014年11月。

Acknowledgements

謝辞

This specification was inspired by an earlier proposal by Eric Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian Smith, Martin Thomson, and others in the TLS Working Group for their feedback and suggestions.

この仕様は、Eric Rescorlaによる以前の提案に触発されました。また、フィードバックと提案を提供してくれたTLSワーキンググループのDaniel Kahn Gillmor、Joe Saloway、Brian Smith、Martin Thomsonなどにも感謝します。

Authors' Addresses

著者のアドレス

Bodo Moeller Google Switzerland GmbH Brandschenkestrasse 110 Zurich 8002 Switzerland

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

   EMail: bmoeller@acm.org

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

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

   EMail: agl@google.com