5. Extension Negotiation (拡張ネゴシエーション)

5.1. Extension Definition (拡張定義)

このドキュメントでは、新しい TLS 拡張 extended_master_secret (拡張タイプ 0x0017) を定義します。これは、クライアントとサーバーの両方に拡張マスターシークレット計算を使用するように合図するために使用されます。この拡張の extension_data フィールドは空です。したがって、拡張のエンコーディング全体は 00 17 00 00 (16進数) です。

このドキュメントでは TLS のみに言及していますが、ここで提案されている拡張は Datagram TLS (DTLS) [RFC6347] でも使用できます。

クライアントとサーバーがこの拡張に同意し、完全なハンドシェイクが行われる場合、クライアントとサーバーの両方は、Section 4 で定義されているように、拡張マスターシークレット導出アルゴリズムを使用しなければなりません (MUST)。その他のすべての暗号計算は変更されません。

5.2. Client and Server Behavior: Full Handshake (クライアントとサーバーの動作：完全なハンドシェイク)

以下では、「ハンドシェイクを中止する」というフレーズを、致命的な handshake_failure アラートを送信してハンドシェイクを終了することの省略形として使用します。

すべてのハンドシェイクにおいて、このドキュメントを実装するクライアントは、ClientHello で extended_master_secret 拡張を送信しなければなりません (MUST)。

このドキュメントを実装するサーバーが extended_master_secret 拡張を受信した場合、ServerHello メッセージにその拡張を含めなければなりません (MUST)。

ClientHello と ServerHello の両方に拡張が含まれている場合、新しいセッションは拡張マスターシークレット計算を使用します。

サーバーが拡張なしで ClientHello を受信した場合、レガシークライアントと相互運用したくない場合は、ハンドシェイクを中止すべきです (SHOULD)。ハンドシェイクを継続することを選択した場合、ServerHello に拡張を含めてはなりません (MUST NOT)。

クライアントが拡張なしで ServerHello を受信した場合、レガシーサーバーと相互運用したくない場合は、ハンドシェイクを中止すべきです (SHOULD)。

クライアントとサーバーが拡張なしで完全なハンドシェイクを継続することを選択した場合、新しいセッションのために標準のマスターシークレット導出を使用しなければなりません (MUST)。この場合、新しいセッションはこのドキュメントで説明されているメカニズムによって保護されません。したがって、実装者は、危険な使用シナリオを回避するために Section 5.4 のガイドラインに従う必要があります。特に、新しいセッションから導出されたマスターシークレットは、アプリケーションレベルの認証に使用すべきではありません。

5.3. Client and Server Behavior: Abbreviated Handshake (クライアントとサーバーの動作：簡略化されたハンドシェイク)

クライアントは、拡張マスターシークレットを使用しないセッションを再開するために簡略化されたハンドシェイクを提供すべきではありません (SHOULD NOT)。代わりに、完全なハンドシェイクを提供すべきです (SHOULD)。

クライアントがレガシーな安全でない再開をサポートするためにそのようなセッションに対しても簡略化されたハンドシェイクを提供することを選択した場合、現在の接続はこのドキュメントのメカニズムによって保護されません。したがって、クライアントは、危険な使用シナリオを回避するために Section 5.4 のガイドラインに従う必要があります。特に、クライアントとサーバーが再ネゴシエーション指示拡張 [RFC5746] をサポートしていても、この接続での再ネゴシエーションはもはや安全ではありません。

簡略化されたハンドシェイクを提供する場合、クライアントは ClientHello で extended_master_secret 拡張を送信しなければなりません (MUST)。

サーバーが既知の以前のセッションの再開を提供する簡略化されたハンドシェイクの ClientHello を受信した場合、次のように動作します。

元のセッションが extended_master_secret 拡張を使用していなかったが、新しい ClientHello に拡張が含まれている場合、サーバーは簡略化されたハンドシェイクを実行してはなりません (MUST NOT)。代わりに、新しいセッションをネゴシエートするために（Section 5.2 で説明されているように）完全なハンドシェイクを継続すべきです (SHOULD)。
元のセッションが extended_master_secret 拡張を使用していたが、新しい ClientHello にそれが含まれていない場合、サーバーは簡略化されたハンドシェイクを中止しなければなりません (MUST)。
元のセッションも新しい ClientHello も拡張を使用していない場合、サーバーはハンドシェイクを中止すべきです (SHOULD)。レガシーな安全でない再開をサポートするために簡略化されたハンドシェイクを継続する場合、接続はこのドキュメントのメカニズムによって保護されなくなり、サーバーは Section 5.4 のガイドラインに従う必要があります。
新しい ClientHello に拡張が含まれており、サーバーがハンドシェイクを継続することを選択した場合、サーバーは ServerHello メッセージに extended_master_secret 拡張を含めなければなりません (MUST)。

クライアントが簡略化されたハンドシェイクを受け入れる ServerHello を受信した場合、次のように動作します。

元のセッションが extended_master_secret 拡張を使用していなかったが、新しい ServerHello に拡張が含まれている場合、クライアントはハンドシェイクを中止しなければなりません (MUST)。
元のセッションが拡張を使用していたが、新しい ServerHello に拡張が含まれていない場合、クライアントはハンドシェイクを中止しなければなりません (MUST)。

クライアントとサーバーが簡略化されたハンドシェイクを継続する場合、通常どおり元のセッションのマスターシークレットから新しいセッションの接続キーを導出します。

5.4. Interoperability Considerations (相互運用性に関する考慮事項)

レガシークライアントおよびサーバーとの相互運用性を可能にするために、TLS ピアは、レガシーマスターシークレット計算を使用する完全なハンドシェイクを受け入れることを決定する場合があります。その場合、セッション状態にフラグを追加して、レガシーマスターシークレットと拡張マスターシークレットを使用するセッションを区別する必要があります。

クライアントまたはサーバーが拡張マスターシークレット拡張なしで完全なハンドシェイクを継続することを選択した場合、新しいセッションは Section 1 で説明されている中間者キー同期攻撃に対して脆弱になります。したがって、クライアントまたはサーバーは、その後のアプリケーションレベルの認証のために、新しいマスターシークレットに基づく鍵素材をエクスポートしてはなりません (MUST NOT)。特に、[RFC5705] および複合認証に依存する Extensible Authentication Protocol (EAP) [COMPOUND-AUTH] を無効にしなければなりません (MUST)。

クライアントまたはサーバーが拡張マスターシークレットを使用しないセッションを再開するために簡略化されたハンドシェイクを継続することを選択した場合、現在の接続は Section 1 で説明されている中間者ハンドシェイクログ同期攻撃に対して脆弱になります。したがって、クライアントまたはサーバーは、アプリケーションレベルの認証に現在のハンドシェイクの verify_data を使用してはなりません (MUST NOT)。特に、クライアントは、現在の接続での再ネゴシエーションおよび "tls-unique" チャネルバインディング [RFC5929] の使用を無効にしなければなりません (MUST)。

元のセッションが拡張マスターシークレットを使用しているが、簡略化されたハンドシェイクの ClientHello または ServerHello に拡張が含まれていない場合、元のセッションの拡張マスターシークレットによって保護されているため、簡略化されたハンドシェイクを継続することは安全である可能性があります (MAY)。このシナリオは、たとえば、この拡張を実装するサーバーがセッションを確立したが、そのセッションがその後、拡張をサポートしない別のサーバーで再開された場合に発生する可能性があります。このような状況はまれであり、一時的または不注意な構成ミスの結果である可能性が高いため、このドキュメントでは、クライアントとサーバーがそのようなハンドシェイクを中止することを推奨します (MUST)。