9. セキュリティに関する考察 (Security Considerations)
TLS に適用されるすべてのセキュリティに関する考察は、QUIC での TLS の使用にも適用されます。[TLS13] とその付録のすべてを読むことが、QUIC のセキュリティ特性を理解するための最良の方法です。
本セクションでは、TLS 統合に固有のより重要なセキュリティ側面のいくつかを要約していますが、文書の残りの部分には多くのセキュリティ関連の詳細があります。
9.1. セッションリンク可能性 (Session Linkability)
TLS セッションチケットの使用により、サーバーおよび場合によっては他のエンティティが、同じクライアントによって確立された接続を関連付けることができます。詳細については、セクション 4.5 を参照してください。
9.2. 0-RTT でのリプレイ攻撃 (Replay Attacks with 0-RTT)
[TLS13] のセクション8で説明されているように、TLS 早期データの使用はリプレイ攻撃にさらされます。QUIC での 0-RTT の使用も同様にリプレイ攻撃に脆弱です。
エンドポイントは [TLS13] で説明されているリプレイ保護を実装して使用しなければなりません (MUST)。ただし、これらの保護は不完全であることが認識されています。したがって、リプレイのリスクに関する追加の考慮が必要です。
QUIC は、運ぶ可能性のあるアプリケーションプロトコル情報を介する場合を除き、リプレイ攻撃に脆弱ではありません。[QUIC-TRANSPORT] で定義されたフレームタイプに基づく QUIC プロトコル状態の管理は、リプレイに脆弱ではありません。QUIC フレームの処理はべき等であり、フレームがリプレイ、再配列、または損失した場合でも、無効な接続状態になることはありません。QUIC 接続は、QUIC が提供するアプリケーションプロトコルによって生成されるものを除いて、接続の存続期間を超えて持続する影響を生成しません。
TLS セッションチケットとアドレス検証トークンは、接続間で QUIC 構成情報を運ぶために使用され、特にサーバーが接続確立とアドレス検証で使用される状態を効率的に復元できるようにします。これらは、エンドポイント間でアプリケーションセマンティクスを通信するために使用してはなりません (MUST NOT)。クライアントはこれらを不透明な値として扱わなければなりません (MUST)。これらのトークンの再利用の可能性は、リプレイに対してより強力な保護が必要であることを意味します。
接続で 0-RTT を受け入れるサーバーは、0-RTT なしで接続を受け入れるよりも高いコストを負担します。これには、より高い処理と計算コストが含まれます。サーバーは、0-RTT を受け入れるときに、リプレイの確率とすべての関連コストを考慮する必要があります。
最終的に、0-RTT でのリプレイ攻撃のリスクを管理する責任は、アプリケーションプロトコルにあります。QUIC を使用するアプリケーションプロトコルは、プロトコルが 0-RTT を使用する方法と、リプレイ攻撃から保護するために採用される措置を記述しなければなりません (MUST)。リプレイリスクの分析では、アプリケーションセマンティクスを運ぶすべての QUIC プロトコル機能を考慮する必要があります。
0-RTT を完全に無効にすることは、リプレイ攻撃に対する最も効果的な防御です。
QUIC 拡張は、リプレイ攻撃がその操作にどのように影響するかを説明するか、0-RTT での拡張の使用を禁止しなければなりません (MUST)。アプリケーションプロトコルは、0-RTT でアプリケーションセマンティクスを運ぶ拡張の使用を禁止するか、リプレイ軽減戦略を提供しなければなりません (MUST)。
9.3. パケット反射攻撃の軽減 (Packet Reflection Attack Mitigation)
サーバーからの大きなハンドシェイクメッセージブロックを生成する小さな ClientHello は、パケット反射攻撃で攻撃者が生成するトラフィックを増幅するために使用できます。
QUIC には、この攻撃に対する3つの防御があります。第一に、ClientHello を含むパケットは最小サイズまでパディングされなければなりません (MUST)。第二に、未検証のソースアドレスに応答する場合、サーバーは受信したバイト数の3倍を超えるバイトを送信することが禁止されています（[QUIC-TRANSPORT] のセクション 8.1 参照）。最後に、Handshake パケットの確認応答は認証されるため、ブラインド攻撃者はそれらを偽造できません。これらの防御を組み合わせることで、増幅のレベルが制限されます。
9.4. ヘッダー保護分析 (Header Protection Analysis)
[NAN] は、ノンスプライバシーを提供する認証暗号化アルゴリズムを分析し、「Hide Nonce (HN)」変換と呼ばれています。本文書の一般的なヘッダー保護構造は、これらのアルゴリズムの1つ (HN1) です。ヘッダー保護は、パケット保護 AEAD の後に適用され、AEAD 出力から一連のバイト（「サンプル」）をサンプリングし、次のように疑似ランダム関数 (PRF) を使用してヘッダーフィールドを暗号化します：
protected_field = field XOR PRF(hp_key, sample)
本文書のヘッダー保護バリアントは、一般的な PRF の代わりに疑似ランダム順列 (PRP) を使用します。ただし、すべての PRP も PRF であるため [IMC]、これらのバリアントは HN1 構造から逸脱しません。
"hp_key" がパケット保護鍵とは異なるため、ヘッダー保護は [NAN] で定義された AE2 セキュリティを達成し、したがって保護されたパケットヘッダーである "field" のプライバシーを保証します。この構造に基づく将来のヘッダー保護バリアントは、同等のセキュリティ保証を確保するために PRF を使用しなければなりません (MUST)。
同じ鍵と暗号文サンプルを複数回使用すると、ヘッダー保護が侵害されるリスクがあります。同じ鍵と暗号文サンプルで2つの異なるヘッダーを保護すると、保護されたフィールドの排他的論理和が明らかになります。AEAD が PRF として機能すると仮定すると、L ビットがサンプリングされる場合、2つの暗号文サンプルが同一である確率は 2^(-L/2) に近づきます。つまり、誕生日境界です。本文書で説明されているアルゴリズムの場合、その確率は 2^64 分の1です。
攻撃者がパケットヘッダーを変更するのを防ぐため、ヘッダーはパケット保護を使用して推移的に認証されます。パケットヘッダー全体が認証された関連データの一部です。偽造または変更された保護されたフィールドは、パケット保護が削除された後にのみ検出できます。
9.5. ヘッダー保護タイミングサイドチャネル (Header Protection Timing Side Channels)
攻撃者は、パケット番号や鍵フェーズの値を推測し、タイミングサイドチャネルを通じてエンドポイントに推測を確認させることができます。同様に、パケット番号長の推測を試みて公開できます。パケットの受信者が、パケット保護を削除しようとせずに重複したパケット番号を持つパケットを破棄する場合、タイミングサイドチャネルを通じてパケット番号が受信したパケットと一致することを明らかにする可能性があります。認証がサイドチャネルから解放されるためには、ヘッダー保護の削除、パケット番号の回復、およびパケット保護の削除のプロセス全体を、タイミングやその他のサイドチャネルなしで一緒に適用しなければなりません (MUST)。
パケットの送信については、パケットペイロードとパケット番号の構築と保護は、パケット番号またはそのエンコードされたサイズを明らかにするサイドチャネルから解放されなければなりません (MUST)。
鍵更新中、新しい鍵を生成するのにかかる時間により、タイミングサイドチャネルを通じて鍵更新が発生したことが明らかになる可能性があります。あるいは、攻撃者がパケットを注入する場合、このサイドチャネルは注入されたパケットの鍵フェーズの値を明らかにする可能性があります。鍵更新を受信した後、エンドポイントは、セクション 6.3 で説明されているように、次のセットの受信パケット保護鍵を生成して保存すべきです (SHOULD)。鍵更新を受信する前に新しい鍵を生成することにより、パケットの受信は鍵フェーズの値を漏洩するタイミング信号を作成しません。
これは、パケット処理中にこの鍵生成を行わないことに依存しており、エンドポイントが受信のために3セットのパケット保護鍵を維持することを要求する場合があります：前の鍵フェーズ用、現在の鍵フェーズ用、および次の鍵フェーズ用。代わりに、エンドポイントは、古い鍵を破棄するまで次の受信パケット保護鍵の生成を延期することを選択でき、その結果、いつでも2セットの受信鍵のみを保持する必要があります。
9.6. 鍵の多様性 (Key Diversity)
TLS を使用する場合、TLS の中央鍵スケジュールが使用されます。TLS ハンドシェイクメッセージが秘密の計算に統合された結果、QUIC トランスポートパラメータ拡張を含めることで、ハンドシェイクおよび 1-RTT 鍵が TCP 上で TLS を実行するサーバーによって生成される可能性のある鍵とは異なることが保証されます。クロスプロトコル鍵同期の可能性を回避するために、鍵分離を改善するための追加措置が提供されます。
QUIC パケット保護鍵と IV は、TLS の同等の鍵とは異なるラベルを使用して派生されます。
この分離を維持するために、QUIC の新しいバージョンでは、パケット保護鍵と IV、およびヘッダー保護鍵の鍵派生に新しいラベルを定義すべきです (SHOULD)。このバージョンの QUIC は文字列 "quic" を使用します。他のバージョンは、その文字列の代わりにバージョン固有のラベルを使用できます。
初期シークレットは、ネゴシエートされた QUIC バージョンに固有の鍵を使用します。新しい QUIC バージョンでは、初期シークレットの計算に使用される新しいソルト値を定義すべきです (SHOULD)。
9.7. ランダム性 (Randomness)
QUIC は、接続 ID などのプロトコル値に直接、および TLS を介して推移的に、エンドポイントが安全な乱数を生成できることに依存しています。安全な乱数生成のガイダンスについては、[RFC4086] を参照してください。