[要約] RFC 7627は、Transport Layer Security (TLS) プロトコルにおける「Session Hash and Extended Master Secret Extension」に関する技術仕様を定めています。この拡張機能の主な目的は、TLSセッションのセキュリティを強化することにあり、特に再接続や派生したセキュリティパラメータの安全性を高めるために設計されています。この拡張により、マスターシークレットを生成する際に、クライアントとサーバー間の全ハンドシェイクメッセージを考慮に入れることができ、マン・イン・ザ・ミドル攻撃に対する保護を強化します。関連するRFCには、TLSの基本を定めるRFC 5246（TLS 1.2）や、後続のTLSバージョンを扱うRFC 8446（TLS 1.3）などがあります。
Internet Engineering Task Force (IETF) K. Bhargavan, Ed.
Request for Comments: 7627 A. Delignat-Lavaud
Updates: 5246 A. Pironti
Category: Standards Track Inria Paris-Rocquencourt
ISSN: 2070-1721 A. Langley
Google Inc.
M. Ray
Microsoft Corp.
September 2015
Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
トランスポート層セキュリティ（TLS）セッションハッシュおよび拡張マスターシークレット拡張
Abstract
概要
The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.
トランスポート層セキュリティ（TLS）マスターシークレットは、サーバー証明書などの重要なセッションパラメータに暗号化されていません。その結果、アクティブな攻撃者が2つのセッションをセットアップする可能性があり、1つはクライアントで、もう1つはサーバーで、2つのセッションのマスターシークレットが同じになるようにします。その後、セッションの再開など、認証にマスターシークレットを使用するメカニズムは、中間者攻撃に対して脆弱になります。この場合、攻撃者はクライアントとサーバーの間でメッセージを簡単にやり取りできます。この仕様は、マスターシークレットを、それを計算する完全なハンドシェイクのログに状況に応じてバインドする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/rfc7627.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7627で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 ....................................................3
2. Requirements Notation ...........................................5
3. The TLS Session Hash ............................................5
4. The Extended Master Secret ......................................6
5. Extension Negotiation ...........................................6
5.1. Extension Definition .......................................6
5.2. Client and Server Behavior: Full Handshake .................7
5.3. Client and Server Behavior: Abbreviated Handshake ..........7
5.4. Interoperability Considerations ............................9
6. Security Considerations .........................................9
6.1. Triple Handshake Preconditions and Impact ..................9
6.2. Cryptographic Properties of the Hash Function .............11
6.3. Handshake Messages Included in the Session Hash ...........11
6.4. No SSL 3.0 Support ........................................12
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Acknowledgments ...................................................14
Authors' Addresses ................................................15
In TLS [RFC5246], every session has a "master_secret" computed as:
TLS [RFC5246]では、すべてのセッションに次のように計算された「master_secret」があります。
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
master_secret = PRF（pre_master_secret、 "master secret"、ClientHello.random + ServerHello.random）[0..47];
where the "pre_master_secret" is the result of some key exchange protocol. For example, when the handshake uses an RSA ciphersuite, this value is generated uniformly at random by the client, whereas for Ephemeral Diffie-Hellman (DHE) ciphersuites, it is the result of a Diffie-Hellman key agreement.
ここで、「pre_master_secret」は、いくつかの鍵交換プロトコルの結果です。たとえば、ハンドシェイクがRSA暗号スイートを使用する場合、この値はクライアントによってランダムに均一に生成されますが、エフェメラルDiffie-Hellman（DHE）暗号スイートの場合、これはDiffie-Hellman鍵合意の結果です。
As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same "master_secret". For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client C connects to a server A. C does not realize that A is malicious and that A connects in the background to an honest server S and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites.
[TRIPLE-HS]で説明されているように、RSAとDHEの両方の鍵交換で、アクティブな攻撃者は2つのTLSセッションを同期して、同じ「master_secret」を共有できます。クライアントが認証されていないRSA鍵交換の場合、これは次のように行われます。クライアントCがサーバーAに接続するとします。Cは、Aが悪意があること、およびAがバックグラウンドで正直なサーバーSに接続し、両方のハンドシェイクを完了することを認識していません。簡単にするために、CとSはRSA暗号スイートのみを使用すると想定します。
1. C sends a "ClientHello" to A, and A forwards it to S.
1. Cは「ClientHello」をAに送信し、AはそれをSに転送します。
2. S sends a "ServerHello" to A, and A forwards it to C.
2. Sは「ServerHello」をAに送信し、AはそれをCに転送します。
3. S sends a "Certificate", containing its certificate chain, to A. A replaces it with its own certificate chain and sends it to C.
3. Sは、証明書チェーンを含む「証明書」をAに送信します。Aは、証明書を独自の証明書チェーンに置き換えて、Cに送信します。
4. S sends a "ServerHelloDone" to A, and A forwards it to C.
4. Sは「ServerHelloDone」をAに送信し、AはそれをCに転送します。
5. C sends a "ClientKeyExchange" to A, containing the "pre_master_secret", encrypted with A's public key. A decrypts the "pre_master_secret", re-encrypts it with S's public key, and sends it on to S.
5. Cは、Aの公開鍵で暗号化された「pre_master_secret」を含む「ClientKeyExchange」をAに送信します。は、「pre_master_secret」を復号化し、Sの公開鍵で再暗号化して、Sに送信します。
6. C sends a "Finished" to A. A computes a "Finished" for its connection with S and sends it to S.
6. Cは「Finished」をAに送信します。AはSとの接続の「Finished」を計算し、それをSに送信します。
7. S sends a "Finished" to A. A computes a "Finished" for its connection with C and sends it to C.
7. Sは「Finished」をAに送信します。AはCとの接続の「Finished」を計算し、それをCに送信します。
At this point, both connections (between C and A, and between A and S) have new sessions that share the same "pre_master_secret", "ClientHello.random", "ServerHello.random", as well as other session parameters, including the session identifier and, optionally, the session ticket. Hence, the "master_secret" value will be equal for the two sessions and will be associated both at C and S with the same session ID, even though the server identities on the two connections are different. Recall that C only sees A's certificate and is unaware of A's connection with S. Moreover, the record keys on the two connections will also be the same.
この時点で、両方の接続（CとAの間、およびAとSの間）には、同じ「pre_master_secret」、「ClientHello.random」、「ServerHello.random」、およびその他のセッションパラメータ（セッション識別子と、オプションでセッションチケット。したがって、「master_secret」値は2つのセッションで等しくなり、2つの接続のサーバーIDが異なっていても、CとSの両方で同じセッションIDに関連付けられます。 CはAの証明書しか認識せず、AとSの接続を認識しないことを思い出してください。さらに、2つの接続のレコードキーも同じになります。
The scenario above shows that TLS does not guarantee that the master secrets and keys used on different connections will be different. Even if client authentication is used, the scenario still works, except that the two sessions now differ on both client and server identities.
上記のシナリオは、TLSが異なる接続で使用されるマスターシークレットとキーが異なることを保証しないことを示しています。クライアント認証が使用されている場合でも、2つのセッションがクライアントIDとサーバーIDの両方で異なることを除いて、シナリオは引き続き機能します。
A similar scenario can be achieved when the handshake uses a DHE ciphersuite. Note that even if the client or server does not prefer using RSA or DHE, the attacker can force them to use it by offering only RSA or DHE in its hello messages. Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. Against more powerful adversaries, other key exchanges, such as Secure Remote Password (SRP) and Pre-Shared Key (PSK), have also been shown to be vulnerable [VERIFIED-BINDINGS].
ハンドシェイクがDHE暗号スイートを使用する場合も、同様のシナリオが実現できます。クライアントまたはサーバーがRSAまたはDHEの使用を好まない場合でも、攻撃者はhelloメッセージでRSAまたはDHEのみを提供することにより、RSAまたはDHEを使用するように強制できることに注意してください。 Ephemeral Elliptic Curve Diffie-Hellman（ECDHE）暗号スイートを使用するハンドシェイクも、任意の明示的な曲線を許可する場合、または小さなサブグループで曲線を使用する場合に脆弱です。より強力な攻撃者に対して、Secure Remote Password（SRP）やPre-Shared Key（PSK）などの他の鍵交換も脆弱性があることが証明されています[検証済みのバインド]。
Once A has synchronized the two connections, since the keys are the same on the two sides, it can step away and transparently forward messages between C and S, reading and modifying when it desires. In the key exchange literature, such occurrences are called unknown key-share attacks, since C and S share a secret but they both think that their secret is shared only with A. In themselves, these attacks do not break integrity or confidentiality between honest parties, but they offer a useful starting point from which to mount impersonation attacks on C and S.
Aが2つの接続を同期すると、キーは2つのサイドで同じであるため、CとSの間でメッセージを段階的に透過的に転送し、必要に応じて読み取りと変更を行うことができます。鍵交換の文献では、CとSは秘密を共有しているため、このような発生は不明な鍵共有攻撃と呼ばれていますが、どちらも自分の秘密はAとのみ共有されていると考えています。これら自体は、正直なパーティ間の整合性や機密性を壊しませんですが、CとSになりすまし攻撃を開始するための出発点として役立ちます。
Suppose C tries to resume its session on a new connection with A. A can then resume its session with S on a new connection and forward the abbreviated handshake messages unchanged between C and S. Since the abbreviated handshake only relies on the master secret for authentication and does not mention client or server identities, both handshakes complete successfully, resulting in the same session keys and the same handshake log. A still knows the connection keys and can send messages to both C and S.
CがAとの新しい接続でセッションを再開しようとするとします。Aは新しい接続でSとのセッションを再開し、CとSの間で変更されていない省略ハンドシェイクメッセージを転送できます。省略ハンドシェイクは認証のマスターシークレットのみに依存しているためまた、クライアントまたはサーバーのIDについては触れていません。どちらのハンドシェイクも正常に完了し、同じセッションキーと同じハンドシェイクログが生成されます。はまだ接続キーを認識しており、CとSの両方にメッセージを送信できます。
Critically, at the new connection, even the handshake log is the same on C and S, thus defeating any man-in-the-middle protection scheme that relies on the uniqueness of finished messages, such as the secure renegotiation indication extension [RFC5746] or TLS channel bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on such session synchronization attacks. In particular, it describes a man-in-the-middle attack, called the "triple handshake", that circumvents the protections of [RFC5746] to break client-authenticated TLS renegotiation after session resumption. Similar attacks apply to application-level authentication mechanisms that rely on channel bindings [RFC5929] or on key material exported from TLS [RFC5705].
重要なのは、新しい接続では、ハンドシェイクログもCとSで同じであるため、安全な再ネゴシエーション表示拡張[RFC5746]など、完成したメッセージの一意性に依存する中間者保護スキームを無効にすることです。またはTLSチャネルバインディング[RFC5929]。 [TRIPLE-HS]は、そのようなセッション同期攻撃に基づくいくつかのエクスプロイトについて説明しています。特に、「トリプルハンドシェイク」と呼ばれる中間者攻撃について説明しており、セッションの再開後に[RFC5746]の保護を回避してクライアント認証のTLS再ネゴシエーションを破ります。同様の攻撃は、チャネルバインディング[RFC5929]またはTLSからエクスポートされたキーマテリアル[RFC5705]に依存するアプリケーションレベルの認証メカニズムに適用されます。
The underlying protocol issue leading to these attacks is that the TLS master secret is not guaranteed to be unique across sessions, since it is not context-bound to the full handshake that generated it. If we fix this problem in the initial master secret computation, then all these attacks can be prevented. This specification introduces a TLS extension that changes the way the "master_secret" value is computed in a full handshake by including the log of the handshake messages, so that different sessions will, by construction, have different master secrets. This prevents the attacks described in [TRIPLE-HS] and documented in Section 2.11 of [RFC7457].
これらの攻撃につながる根本的なプロトコルの問題は、TLSマスターシークレットが生成された完全なハンドシェイクにコンテキストバインドされていないため、TLSマスターシークレットがセッション全体で一意であることが保証されないことです。最初のマスターシークレットの計算でこの問題を修正すると、これらすべての攻撃を防ぐことができます。この仕様では、ハンドシェイクメッセージのログを含めることにより、フルハンドシェイクでの "master_secret"値の計算方法を変更するTLS拡張が導入されているため、異なるセッションは、構造上、異なるマスターシークレットを持ちます。これにより、[TRIPLE-HS]で説明され、[RFC7457]のセクション2.11で説明されている攻撃が防止されます。
This document uses the same notation and terminology used in the TLS protocol specification [RFC5246].
このドキュメントでは、TLSプロトコル仕様[RFC5246]で使用されているものと同じ表記法と用語を使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
When a full TLS handshake takes place, we define
完全なTLSハンドシェイクが発生すると、
session_hash = Hash(handshake_messages)
session_hash = Hash（handshake_messages）
where "handshake_messages" refers to all handshake messages sent or received, starting at the ClientHello up to and including the ClientKeyExchange message, including the type and length fields of the handshake messages. This is the concatenation of all the exchanged Handshake structures, as defined in Section 7.4 of [RFC5246].
ここで、「handshake_messages」は、ClientHelloからClientKeyExchangeメッセージまでの、送受信されたすべてのハンドシェイクメッセージを指します。これには、ハンドシェイクメッセージのタイプフィールドと長さフィールドが含まれます。これは、[RFC5246]のセクション7.4で定義されている、交換されたすべてのハンドシェイク構造の連結です。
For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 of [RFC5246] for the Finished message computation. For all previous versions of TLS, the "Hash" function computes the concatenation of MD5 and SHA1.
TLS 1.2の場合、「ハッシュ」関数は、[RFC5246]のセクション7.4.9で定義された、完了したメッセージの計算用の関数です。 TLSの以前のすべてのバージョンでは、「ハッシュ」関数はMD5とSHA1の連結を計算します。
There is no "session_hash" for resumed handshakes, as they do not lead to the creation of a new session.
新しいセッションの作成につながらないため、再開されたハンドシェイクには「session_hash」はありません。
When the extended master secret extension is negotiated in a full handshake, the "master_secret" is computed as
拡張マスターシークレット拡張がフルハンドシェイクでネゴシエートされると、「master_secret」は次のように計算されます。
master_secret = PRF(pre_master_secret, "extended master secret", session_hash) [0..47];
master_secret = PRF（pre_master_secret、 "extended master secret"、session_hash）[0..47];
The extended master secret computation differs from that described in [RFC5246] in the following ways:
拡張マスターシークレットの計算は、[RFC5246]で説明されているものとは次の点で異なります。
o The "extended master secret" label is used instead of "master secret".
o 「マスターシークレット」の代わりに「拡張マスターシークレット」ラベルが使用されます。
o The "session_hash" is used instead of the "ClientHello.random" and "ServerHello.random".
o 「ClientHello.random」および「ServerHello.random」の代わりに「session_hash」が使用されます。
The "session_hash" depends upon a handshake log that includes "ClientHello.random" and "ServerHello.random", in addition to ciphersuites, key exchange information, and certificates (if any) from the client and server. Consequently, the extended master secret depends upon the choice of all these session parameters.
「session_hash」は、暗号スイート、鍵交換情報、およびクライアントとサーバーからの証明書（存在する場合）に加えて、「ClientHello.random」と「ServerHello.random」を含むハンドシェイクログに依存します。したがって、拡張マスターシークレットは、これらすべてのセッションパラメータの選択に依存します。
This design reflects the recommendation that keys should be bound to the security contexts that compute them [SP800-108]. The technique of mixing a hash of the key exchange messages into master key derivation is already used in other well-known protocols such as Secure Shell (SSH) [RFC4251].
この設計は、キーをそれらを計算するセキュリティコンテキストにバインドするという推奨事項を反映しています[SP800-108]。鍵交換メッセージのハッシュをマスター鍵導出に混合する手法は、Secure Shell（SSH）[RFC4251]などの他のよく知られたプロトコルですでに使用されています。
Clients and servers SHOULD NOT accept handshakes that do not use the extended master secret, especially if they rely on features like compound authentication that fall into the vulnerable cases described in Section 6.1.
クライアントとサーバーは、拡張マスターシークレットを使用しないハンドシェイクを受け入れないでください（特に、セクション6.1で説明されている脆弱なケースに該当する複合認証などの機能に依存している場合）。
This document defines a new TLS extension, "extended_master_secret" (with extension type 0x0017), which is used to signal both client and server to use the extended master secret computation. The "extension_data" field of this extension is empty. Thus, the entire encoding of the extension is 00 17 00 00 (in hexadecimal.)
このドキュメントでは、新しいTLS拡張「extended_master_secret」（拡張タイプ0x0017）を定義します。これは、拡張マスターシークレット計算を使用するようにクライアントとサーバーの両方に通知するために使用されます。この拡張の「extension_data」フィールドは空です。したがって、拡張子のエンコード全体は00 17 00 00（16進数）です。
Although this document refers only to TLS, the extension proposed here can also be used with Datagram TLS (DTLS) [RFC6347].
このドキュメントはTLSのみを参照していますが、ここで提案されている拡張機能は、データグラムTLS（DTLS）[RFC6347]でも使用できます。
If the client and server agree on this extension and a full handshake takes place, both client and server MUST use the extended master secret derivation algorithm, as defined in Section 4. All other cryptographic computations remain unchanged.
クライアントとサーバーがこの拡張に同意し、完全なハンドシェイクが行われる場合、クライアントとサーバーの両方が、セクション4で定義されている拡張マスターシークレット導出アルゴリズムを使用する必要があります。他のすべての暗号計算は変更されません。
In the following, we use the phrase "abort the handshake" as shorthand for terminating the handshake by sending a fatal "handshake_failure" alert.
以下では、致命的な「handshake_failure」アラートを送信してハンドシェイクを終了するための省略形として、「ハンドシェイクを中止する」というフレーズを使用しています。
In all handshakes, a client implementing this document MUST send the "extended_master_secret" extension in its ClientHello.
すべてのハンドシェイクで、このドキュメントを実装するクライアントは、ClientHelloで「extended_master_secret」拡張を送信する必要があります。
If a server implementing this document receives the "extended_master_secret" extension, it MUST include the extension in its ServerHello message.
このドキュメントを実装するサーバーが「extended_master_secret」拡張機能を受信する場合、ServerHelloメッセージに拡張機能を含める必要があります。
If both the ClientHello and ServerHello contain the extension, the new session uses the extended master secret computation.
ClientHelloとServerHelloの両方に拡張が含まれている場合、新しいセッションは拡張マスターシークレット計算を使用します。
If the server receives a ClientHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy clients. If it chooses to continue the handshake, then it MUST NOT include the extension in the ServerHello.
サーバーが拡張機能なしでClientHelloを受信した場合、レガシークライアントと相互運用したくない場合は、ハンドシェイクを中止する必要があります。ハンドシェイクを続行することを選択した場合、ServerHelloに拡張を含めてはなりません（MUST NOT）。
If a client receives a ServerHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy servers.
クライアントが拡張なしでServerHelloを受信した場合、レガシーサーバーとの相互運用を望まない場合は、ハンドシェイクを中止する必要があります。
If the client and server choose to continue a full handshake without the extension, they MUST use the standard master secret derivation for the new session. In this case, the new session is not protected by the mechanisms described in this document. So, implementers should follow the guidelines in Section 5.4 to avoid dangerous usage scenarios. In particular, the master secret derived from the new session should not be used for application-level authentication.
クライアントとサーバーが拡張なしで完全なハンドシェイクを続行することを選択した場合、それらは新しいセッションに標準のマスターシークレットの派生を使用する必要があります。この場合、新しいセッションは、このドキュメントで説明されているメカニズムによって保護されません。したがって、実装者はセクション5.4のガイドラインに従って、危険な使用シナリオを回避する必要があります。特に、新しいセッションから派生したマスターシークレットは、アプリケーションレベルの認証には使用しないでください。
The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret. Instead, it SHOULD offer a full handshake.
クライアントは、拡張マスターシークレットを使用しないセッションを再開するために、短縮ハンドシェイクを提供してはなりません（SHOULD NOT）。代わりに、完全なハンドシェイクを提供する必要があります。
If the client chooses to offer an abbreviated handshake even for such sessions in order to support legacy insecure resumption, then the current connection is not protected by the mechanisms in this document. So, the client should follow the guidelines in Section 5.4
レガシーの安全でない再開をサポートするために、クライアントがそのようなセッションに対しても短縮ハンドシェイクを提供することを選択した場合、現在の接続はこのドキュメントのメカニズムによって保護されません。したがって、クライアントはセクション5.4のガイドラインに従う必要があります。
to avoid dangerous usage scenarios. In particular, renegotiation is no longer secure on this connection, even if the client and server support the renegotiation indication extension [RFC5746].
危険な使用シナリオを回避するため。特に、クライアントとサーバーが再ネゴシエーション表示拡張[RFC5746]をサポートしていても、この接続では再ネゴシエーションは安全ではありません。
When offering an abbreviated handshake, the client MUST send the "extended_master_secret" extension in its ClientHello.
省略されたハンドシェイクを提供する場合、クライアントはそのClientHelloで「extended_master_secret」拡張を送信する必要があります。
If a server receives a ClientHello for an abbreviated handshake offering to resume a known previous session, it behaves as follows:
サーバーは、既知の以前のセッションを再開するための省略されたハンドシェイクオファリングのClientHelloを受信すると、次のように動作します。
o If the original session did not use the "extended_master_secret" extension but the new ClientHello contains the extension, then the server MUST NOT perform the abbreviated handshake. Instead, it SHOULD continue with a full handshake (as described in Section 5.2) to negotiate a new session.
o 元のセッションが「extended_master_secret」拡張を使用しなかったが、新しいClientHelloに拡張が含まれている場合、サーバーは省略されたハンドシェイクを実行してはならない（MUST NOT）。代わりに、新しいセッションをネゴシエートするために（セクション5.2で説明されているように）完全なハンドシェイクを続行する必要があります（SHOULD）。
o If the original session used the "extended_master_secret" extension but the new ClientHello does not contain it, the server MUST abort the abbreviated handshake.
o 元のセッションが「extended_master_secret」拡張を使用したが、新しいClientHelloにそれが含まれていない場合、サーバーは省略されたハンドシェイクを中止する必要があります。
o If neither the original session nor the new ClientHello uses the extension, the server SHOULD abort the handshake. If it continues with an abbreviated handshake in order to support legacy insecure resumption, the connection is no longer protected by the mechanisms in this document, and the server should follow the guidelines in Section 5.4.
o 元のセッションも新しいClientHelloも拡張機能を使用しない場合、サーバーはハンドシェイクを中止する必要があります（SHOULD）。レガシーの安全でない再開をサポートするために簡略化されたハンドシェイクが続く場合、接続はこのドキュメントのメカニズムによって保護されなくなり、サーバーはセクション5.4のガイドラインに従う必要があります。
o If the new ClientHello contains the extension and the server chooses to continue the handshake, then the server MUST include the "extended_master_secret" extension in its ServerHello message.
o 新しいClientHelloが拡張を含み、サーバーがハンドシェイクを続行することを選択した場合、サーバーはそのServerHelloメッセージに「extended_master_secret」拡張を含める必要があります。
If a client receives a ServerHello that accepts an abbreviated handshake, it behaves as follows:
クライアントが省略されたハンドシェイクを受け入れるServerHelloを受信した場合、クライアントは次のように動作します。
o If the original session did not use the "extended_master_secret" extension but the new ServerHello contains the extension, the client MUST abort the handshake.
o 元のセッションが「extended_master_secret」拡張を使用しなかったが、新しいServerHelloに拡張が含まれている場合、クライアントはハンドシェイクを中止する必要があります。
o If the original session used the extension but the new ServerHello does not contain the extension, the client MUST abort the handshake.
o 元のセッションが拡張を使用したが、新しいServerHelloに拡張が含まれていない場合、クライアントはハンドシェイクを中止する必要があります。
If the client and server continue the abbreviated handshake, they derive the connection keys for the new session as usual from the master secret of the original session.
クライアントとサーバーが短縮ハンドシェイクを続行する場合、それらは通常どおり、元のセッションのマスターシークレットから新しいセッションの接続キーを取得します。
To allow interoperability with legacy clients and servers, a TLS peer may decide to accept full handshakes that use the legacy master secret computation. If so, they need to differentiate between sessions that use legacy and extended master secrets by adding a flag to the session state.
従来のクライアントおよびサーバーとの相互運用を可能にするために、TLSピアは、従来のマスターシークレット計算を使用する完全なハンドシェイクを受け入れることを決定する場合があります。その場合、セッション状態にフラグを追加することで、レガシーと拡張マスターシークレットを使用するセッションを区別する必要があります。
If a client or server chooses to continue with a full handshake without the extended master secret extension, then the new session becomes vulnerable to the man-in-the-middle key synchronization attack described in Section 1. Hence, the client or server MUST NOT export any key material based on the new master secret for any subsequent application-level authentication. In particular, it MUST disable [RFC5705] and any Extensible Authentication Protocol (EAP) relying on compound authentication [COMPOUND-AUTH].
クライアントまたはサーバーが、拡張されたマスターシークレット拡張なしでフルハンドシェイクを続行することを選択した場合、新しいセッションは、セクション1で説明されている中間者キー同期攻撃に対して脆弱になります。したがって、クライアントまたはサーバーは、後続のアプリケーションレベルの認証のために、新しいマスターシークレットに基づいてキーマテリアルをエクスポートします。特に、[RFC5705]と複合認証[COMPOUND-AUTH]に依存する拡張認証プロトコル（EAP）を無効にする必要があります。
If a client or server chooses to continue an abbreviated handshake to resume a session that does not use the extended master secret, then the current connection becomes vulnerable to a man-in-the-middle handshake log synchronization attack as described in Section 1. Hence, the client or server MUST NOT use the current handshake's "verify_data" for application-level authentication. In particular, the client MUST disable renegotiation and any use of the "tls-unique" channel binding [RFC5929] on the current connection.
クライアントまたはサーバーが省略されたハンドシェイクを継続して拡張マスターシークレットを使用しないセッションを再開することを選択した場合、セクション1で説明されているように、現在の接続は中間者ハンドシェイクログ同期攻撃に対して脆弱になります。 、クライアントまたはサーバーは、アプリケーションレベルの認証に現在のハンドシェイクの「verify_data」を使用してはなりません（MUST NOT）。特に、クライアントは現在の接続での再ネゴシエーションと「tls-unique」チャネルバインディング[RFC5929]の使用を無効にしなければなりません（MUST）。
If the original session uses an extended master secret but the ClientHello or ServerHello in the abbreviated handshake does not include the extension, it MAY be safe to continue the abbreviated handshake since it is protected by the extended master secret of the original session. This scenario may occur, for example, when a server that implements this extension establishes a session but the session is subsequently resumed at a different server that does not support the extension. Since such situations are unusual and likely to be the result of transient or inadvertent misconfigurations, this document recommends that the client and server MUST abort such handshakes.
元のセッションが拡張マスターシークレットを使用しているが、省略ハンドシェイクのClientHelloまたはServerHelloに拡張が含まれていない場合、元のセッションの拡張マスターシークレットによって保護されているため、省略ハンドシェイクを続行しても安全です。このシナリオは、たとえば、この拡張機能を実装するサーバーがセッションを確立した後、その拡張機能をサポートしていない別のサーバーでセッションが再開された場合に発生する可能性があります。このような状況は異常であり、一時的または不注意な設定ミスの結果である可能性が高いため、このドキュメントでは、クライアントとサーバーがそのようなハンドシェイクを中止する必要があることを推奨しています。
One way to mount a triple handshake attack is described in Section 1, along with a mention of the security mechanisms that break due to the attack; more in-depth discussion and diagrams can be found in [TRIPLE-HS]. Here, some further discussion is presented about attack preconditions and impact.
トリプルハンドシェイク攻撃を開始する1つの方法は、第1章で説明されており、攻撃によって破壊されるセキュリティメカニズムについても説明されています。詳細な説明と図は[TRIPLE-HS]にあります。ここでは、攻撃の前提条件と影響について、さらにいくつかの議論が行われます。
To mount a triple handshake attack, it must be possible to force the same master secret on two different sessions. For this to happen, two preconditions must be met:
トリプルハンドシェイク攻撃を開始するには、2つの異なるセッションで同じマスターシークレットを強制的に実行できる必要があります。これを実現するには、2つの前提条件を満たす必要があります。
o The client, C, must be willing to connect to a malicious server, A. In certain contexts, like the web, this can be easily achieved, since a browser can be instructed to load content from an untrusted origin.
o クライアントCは、悪意のあるサーバーAに接続しようとする必要があります。Webなどの特定のコンテキストでは、信頼できないオリジンからコンテンツをロードするようにブラウザーに指示できるため、これは簡単に実現できます。
o The pre-master secret must be synchronized on the two sessions. This is particularly easy to achieve with the RSA and DHE key exchanges, but under some conditions, ECDHE, SRP, and PSK key exchanges can be exploited to this effect as well.
o プレマスターシークレットは、2つのセッションで同期する必要があります。これは、RSAおよびDHEのキー交換で特に簡単に実現できますが、状況によっては、ECDHE、SRP、およびPSKのキー交換を利用して、この効果を実現することもできます。
Once the master secret is synchronized on two sessions, any security property that relies on the uniqueness of the master secret is compromised. For example, a TLS exporter [RFC5705] no longer provides a unique key bound to the current session.
マスターシークレットが2つのセッションで同期されると、マスターシークレットの一意性に依存するセキュリティプロパティはすべて侵害されます。たとえば、TLSエクスポーター[RFC5705]は、現在のセッションにバインドされた一意のキーを提供しなくなりました。
TLS session resumption also relies on the uniqueness of the master secret to authenticate the resuming peers. Hence, if a synchronized session is resumed, the peers cannot be sure about each other's identities, and the attacker knows the connection keys. Clearly, a precondition to this step of the attack is that both client and server support session resumption (either via session identifier or session tickets [RFC5077]).
TLSセッションの再開は、再開するピアを認証するためにマスターシークレットの一意性にも依存します。したがって、同期セッションが再開された場合、ピアは互いのIDを確認できず、攻撃者は接続キーを知っています。明らかに、攻撃のこのステップの前提条件は、クライアントとサーバーの両方が（セッション識別子またはセッションチケット[RFC5077]を介して）セッションの再開をサポートすることです。
Additionally, in a synchronized abbreviated handshake, the whole transcript (which includes the "verify_data" values) is synchronized. So, after an abbreviated handshake, channel bindings like "tls-unique" [RFC5929] will not uniquely identify the connection anymore.
さらに、同期された省略ハンドシェイクでは、トランスクリプト全体（「verify_data」値を含む）が同期されます。したがって、省略されたハンドシェイクの後、「tls-unique」[RFC5929]のようなチャネルバインディングは接続を一意に識別しなくなります。
Synchronization of the "verify_data" in abbreviated handshakes also undermines the security guarantees of the renegotiation indication extension [RFC5746], re-enabling a prefix-injection flaw similar to the renegotiation attack [Ray09]. However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes. Hence, a precondition to mount this stage of the attack is that the client accepts different certificates at each handshake, even if their common names do not match. Before the triple handshake attack was discovered, this used to be widespread behavior, at least among some web browsers; such browsers were hence vulnerable to the attack.
省略されたハンドシェイクでの「verify_data」の同期は、再ネゴシエーション表示拡張[RFC5746]のセキュリティ保証を損ない、再ネゴシエーション攻撃[Ray09]と同様のプレフィックス挿入の欠陥を再び有効にします。ただし、トリプルハンドシェイク攻撃では、クライアントはサーバー証明書がさまざまなフルハンドシェイクにわたって変化するのを見ます。したがって、攻撃のこの段階を開始するための前提条件は、共通名が一致しない場合でも、クライアントが各ハンドシェイクで異なる証明書を受け入れることです。トリプルハンドシェイク攻撃が発見される前は、これは、少なくとも一部のWebブラウザーで広く使われていた振る舞いでした。したがって、そのようなブラウザは攻撃に対して脆弱でした。
The extended master secret extension thwarts triple handshake attacks at their first stage by ensuring that different sessions necessarily end up with different master secret values. Hence, all security properties relying on the uniqueness of the master secret are now expected to hold. In particular, if a TLS session is protected by the extended master secret extension, it is safe to resume it, to use its channel bindings, and to allow for certificate changes across renegotiation, meaning that all certificates are controlled by the same peer. A symbolic cryptographic protocol analysis justifying the extended master secret extension appears in [VERIFIED-BINDINGS].
拡張マスターシークレット拡張は、異なるセッションが必然的に異なるマスターシークレット値になることを保証することにより、最初の段階でトリプルハンドシェイク攻撃を阻止します。したがって、マスターシークレットの一意性に依存するすべてのセキュリティプロパティが保持されることが期待されています。特に、TLSセッションが拡張マスターシークレット拡張によって保護されている場合、セッションを再開し、そのチャネルバインディングを使用して、再ネゴシエーション全体で証明書の変更を許可しても安全です。つまり、すべての証明書が同じピアによって制御されます。拡張マスターシークレット拡張を正当化するシンボリック暗号プロトコル分析が[VERIFIED-BINDINGS]に表示されます。
The session hashes of two different sessions need to be distinct; hence, the "Hash" function used to compute the "session_hash" needs to be collision resistant. As such, hash functions such as MD5 or SHA1 are NOT RECOMMENDED.
2つの異なるセッションのセッションハッシュは異なる必要があります。したがって、「session_hash」を計算するために使用される「ハッシュ」関数は、耐衝突性である必要があります。そのため、MD5やSHA1などのハッシュ関数は推奨されません。
We observe that the "Hash" function used in the Finished message computation already needs to be collision resistant for the renegotiation indication extension [RFC5746] to work, because a meaningful collision on the handshake messages (and hence on the "verify_data") may re-enable the renegotiation attack [Ray09].
完了メッセージの計算で使用される「ハッシュ」関数は、再ネゴシエーション表示拡張[RFC5746]が機能するために、耐衝突性がすでに必要であることがわかります。 -再交渉攻撃を有効にします[Ray09]。
The hash function used to compute the session hash depends on the TLS protocol version. All current ciphersuites defined for TLS 1.2 use SHA256 or better, and so does the session hash. For earlier versions of the protocol, only MD5 and SHA1 can be assumed to be supported, and this document does not require legacy implementations to add support for new hash functions. In these versions, the session hash uses the concatenation of MD5 and SHA1, as in the Finished message.
セッションハッシュの計算に使用されるハッシュ関数は、TLSプロトコルのバージョンによって異なります。 TLS 1.2で定義されている現在のすべての暗号スイートはSHA256以上を使用し、セッションハッシュも使用します。プロトコルの以前のバージョンの場合、サポートされると想定できるのはMD5とSHA1のみであり、このドキュメントでは、新しいハッシュ関数のサポートを追加するためのレガシー実装は必要ありません。これらのバージョンでは、セッションハッシュはMD5とSHA1を連結したものを使用して、Finishedメッセージと同様に処理します。
The "session_hash" is intended to encompass all relevant session information, including ciphersuite negotiation, key exchange messages, and client and server identities. The hash is needed to compute the extended master secret and hence must be available before the Finished messages.
「session_hash」は、暗号スイートネゴシエーション、鍵交換メッセージ、クライアントとサーバーの識別情報など、関連するすべてのセッション情報を網羅することを目的としています。ハッシュは、拡張マスターシークレットを計算するために必要であるため、完了メッセージの前に利用可能である必要があります。
This document sets the "session_hash" to cover all handshake messages up to and including the ClientKeyExchange. For existing TLS ciphersuites, these messages include all the significant contents of the new session -- CertificateVerify does not change the session content. At the same time, this allows the extended master secret to be computed immediately after the pre-master secret, so that implementations can shred the temporary pre-master secret from memory as early as possible.
このドキュメントは、ClientKeyExchangeまでのすべてのハンドシェイクメッセージをカバーするように「session_hash」を設定します。既存のTLS暗号スイートの場合、これらのメッセージには新しいセッションの重要なコンテンツがすべて含まれています。CertificateVerifyはセッションのコンテンツを変更しません。同時に、これにより、拡張マスターシークレットをプリマスターシークレットの直後に計算できるため、実装は一時プリマスターシークレットをメモリからできるだけ早くシュレッドできます。
It is possible that new ciphersuites or TLS extensions may include additional messages between ClientKeyExchange and Finished that add important session context. In such cases, some of the security guarantees of this specification may no longer apply, and new man-in-the-middle attacks may be possible. For example, if the client and server support the session ticket extension [RFC5077], the session hash does not cover the new session ticket sent by the server. Hence, a man-in-the-middle may be able to cause a client to store a session ticket that was not meant for the current session. Attacks based on this vector are not yet known, but applications that store additional information in session tickets beyond those covered in the session hash require careful analysis.
新しい暗号スイートまたはTLS拡張には、ClientKeyExchangeとFinishedの間に重要なセッションコンテキストを追加する追加のメッセージが含まれている可能性があります。そのような場合、この仕様のセキュリティ保証の一部が適用されなくなり、新たな中間者攻撃が可能になる可能性があります。たとえば、クライアントとサーバーがセッションチケット拡張[RFC5077]をサポートしている場合、セッションハッシュはサーバーによって送信された新しいセッションチケットをカバーしません。したがって、中間者は、クライアントに、現在のセッション用ではないセッションチケットを保存させることができる場合があります。このベクトルに基づく攻撃はまだ知られていませんが、セッションハッシュでカバーされるもの以外の追加情報をセッションチケットに格納するアプリケーションは、注意深い分析が必要です。
The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is equally vulnerable to triple handshake attacks, alongside other vulnerabilities stemming from its use of obsolete cryptographic constructions that are now considered weak. SSL 3.0 has been deprecated [RFC7568].
Secure Sockets Layer（SSL）プロトコルバージョン3.0 [RFC6101]はTLSプロトコルの前身であり、トリプルハンドシェイク攻撃に対して同様に脆弱であり、現在弱体と見なされている古い暗号化構造の使用に起因する他の脆弱性も同様です。 SSL 3.0は非推奨になりました[RFC7568]。
The countermeasure described in this document relies on a TLS extension and hence cannot be used with SSL 3.0. Clients and servers implementing this document SHOULD refuse SSL 3.0 handshakes. If they choose to support SSL 3.0, the resulting sessions MUST use the legacy master secret computation, and the interoperability considerations of Section 5.4 apply.
このドキュメントで説明されている対策はTLS拡張に依存しているため、SSL 3.0では使用できません。このドキュメントを実装するクライアントとサーバーは、SSL 3.0ハンドシェイクを拒否する必要があります。 SSL 3.0をサポートすることを選択した場合、結果のセッションはレガシーマスターシークレット計算を使用する必要があり、セクション5.4の相互運用性に関する考慮事項が適用されます。
IANA has added the extension code point 23 (0x0017), which has been used by prototype implementations, for the "extended_master_secret" extension to the "ExtensionType Values" registry specified in the TLS specification [RFC5246].
IANAは、「extended_master_secret」拡張用のプロトタイプ実装で使用されている拡張コードポイント23（0x0017）を、TLS仕様[RFC5246]で指定されている「ExtensionType値」レジストリに追加しました。
[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>。
[COMPOUND-AUTH] Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication Protocols", Security Protocols, LNCS, Volume 3364, DOI 10.1007/11542322_6, 2005.
[COMPOUND-AUTH] Asokan、N.、Valtteri、N。、およびK. Nyberg、「トンネル認証プロトコルの中間者」、セキュリティプロトコル、LNCS、ボリューム3364、DOI 10.1007 / 11542322_6、2005。
[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.
[Ray09] Ray、M。、「TLS再ネゴシエーションにおける認証ギャップ」、2009年。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<http://www.rfc-editor.org/ info / rfc4251>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without server-Side State」、RFC 5077、DOI 10.17487 / RFC5077、January 2008、 <http://www.rfc-editor.org/info/rfc5077>。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5705] Rescorla、E。、「トランスポート層セキュリティ（TLS）の鍵となるマテリアルエクスポーター」、RFC 5705、DOI 10.17487 / RFC5705、2010年3月、<http://www.rfc-editor.org/info/rfc5705>。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、DOI 10.17487 / RFC5746、2010年2月、<http：/ /www.rfc-editor.org/info/rfc5746>。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <http://www.rfc-editor.org/info/rfc5929>.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、DOI 10.17487 / RFC5929、2010年7月、<http://www.rfc-editor.org/info / rfc5929>。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, 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、DOI 10.17487 / RFC6101、2011年8月、<http：//www.rfc -editor.org/info/rfc6101>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、 <http://www.rfc-editor.org/info/rfc7457>。
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <http://www.rfc-editor.org/info/rfc7568>.
[RFC7568] Barnes、R.、Thomson、M.、Pironti、A。、およびA. Langley、「Deprecating Secure Sockets Layer Version 3.0」、RFC 7568、DOI 10.17487 / RFC7568、2015年6月、<http：// www。 rfc-editor.org/info/rfc7568>。
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", NIST Special Publication 800-108, 2009.
[SP800-108]チェンL.、「疑似ランダム関数を使用した鍵導出の推奨（改訂版）」、NIST Special Publication 800-108、2009。
[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, 2014.
[TRIPLE-HS] Bhargavan、K.、Delignat-Lavaud、A.、Fournet、C.、Pironti、A。、およびP-Y。 Strub、「Triple Handshake and Cookie Cutters：Breaking and Fixing Authentication over TLS」、IEEE Symposium on Security and Privacy、DOI 10.1109 / SP.2014.14、2014。
[VERIFIED-BINDINGS] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, "Verified Contributive Channel Bindings for Compound Authentication", Network and Distributed System Security Symposium (NDSS), 2015.
[検証済みのバインディング] Bhargavan、K.、Delignat-Lavaud、A。、およびA. Pironti、「検証済みのコントリビューティブチャネルバインディング、複合認証」、ネットワークおよび分散システムセキュリティシンポジウム（NDSS）、2015年。
Acknowledgments
謝辞
Triple handshake attacks were originally discovered by Antoine Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti. They were further developed by the miTLS team: Cedric Fournet, Pierre-Yves Strub, Markulf Kohlweiss, and Santiago Zanella-Beguelin. Many of the ideas in this document emerged from discussions with Martin Abadi, Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric Rescorla, Martin Rex, and Brian Smith.
トリプルハンドシェイク攻撃は、Antoine Delignat-Lavaud、Karthikeyan Bhargavan、およびAlfredo Pirontiによって最初に発見されました。それらはmiTLSチームによってさらに開発されました：セドリックフルネット、ピエールイヴストラブ、マルクルフコールワイス、およびサンティアゴザネラベグリン。このドキュメントのアイデアの多くは、Martin Abadi、Ben Laurie、Nikos Mavrogiannopoulos、Manuel Pegourie-Gonnard、Eric Rescorla、Martin Rex、およびBrian Smithとの話し合いから生まれました。
Authors' Addresses
著者のアドレス
Karthikeyan Bhargavan (editor) Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
Karthikeyan Bhargavan（editor）Inria Paris-Rocquencourt 23、Avenue d'Italie Paris 75214 CEDEX 13 France
Email: karthikeyan.bhargavan@inria.fr
Antoine Delignat-Lavaud Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
Antoine Delignat-Lavaud Inria Paris-Rocquencourt 23、Avenue d'Italie Paris 75214 CEDEX 13 France
Email: antoine.delignat-lavaud@inria.fr
Alfredo Pironti Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
Alfredo Pironti Inria Paris-Rocquencourt 23、Avenue d'Italie Paris 75214 CEDEX 13 France
Email: alfredo.pironti@inria.fr
Adam Langley Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Adam Langley Google Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: agl@google.com
Marsh Ray Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 United States
Marsh Ray Microsoft Corp. 1 Microsoft Way Redmond、WA 98052 United States
Email: maray@microsoft.com