2.1. TLSの概要

TLSは、2つのエンドポイントが信頼できない媒体（たとえばインターネット）上で 通信手段を確立する方法を提供します。TLSはピアの認証を可能にし、 エンドポイント間で交換されるメッセージの機密性と完全性を 保護します。¶

内部的には、TLSは階層化されたプロトコルであり、その構造を 図1に示します。¶

          +-------------+------------+--------------+---------+
コンテンツ|             |            |アプリケーション|         |
レイヤー  |ハンドシェイク|  アラート  |    データ      |   ...   |
          |             |            |              |         |
          +-------------+------------+--------------+---------+
レコード  |                                                   |
レイヤー  |                    レコード                       |
          |                                                   |
          +---------------------------------------------------+

各コンテンツレイヤーのメッセージ（たとえば、ハンドシェイク、アラート、アプリケーションデータ）は、 レコードレイヤーによって一連の型付きTLSレコードとして伝送されます。レコードは 個別に暗号学的保護が施された後、順序付けと確実な配信を提供する 信頼性のあるトランスポート（通常はTCP）上で送信されます。¶

TLSの認証付き鍵交換は、クライアントと サーバーという2つのエンドポイント間で行われます。クライアントが交換を開始し、サーバーが応答します。鍵 交換が正常に完了すると、クライアントとサーバーの両方がシークレットについて合意します。 TLSは、事前共有鍵（PSK）と、有限 体または楕円曲線上のDiffie-Hellman（(EC)DHE）鍵交換の両方をサポートします。PSKはEarly Data（0-RTT）の基礎となります。後者は、(EC)DHE 鍵が破棄された場合に前方秘匿性（FS）を提供します。2つのモードを組み合わせて、PSKを認証に使用しながら 前方秘匿性を提供することもできます。¶

TLSハンドシェイクが完了すると、クライアントはサーバーの IDを取得して認証しており、サーバーは任意で クライアントのIDを取得して認証できます。TLSは、サーバーとクライアントの両方についてX.509 [RFC5280]証明書ベースの認証をサポートします。 PSK鍵交換が使用される場合（再開時など）、PSKを知っていることが ピアの認証として機能します。¶

TLS鍵交換は攻撃者による改ざんに耐性があり、 参加するどちらのピアも制御できない共有シークレットを生成します。¶

TLSは、QUICに関連する2つの基本的なハンドシェイクモードを提供します。¶

• 完全な1-RTTハンドシェイクでは、クライアントは 1回のラウンドトリップ後にアプリケーションデータを送信でき、サーバーはクライアントから 最初のハンドシェイクメッセージを受信した直後に応答します。¶
• 0-RTTハンドシェイクでは、クライアントは以前に サーバーについて取得した情報を使用して、アプリケーションデータを直ちに送信します。この アプリケーションデータは攻撃者によってリプレイされる可能性があるため、0-RTTは リプレイされた場合に望ましくない影響を引き起こす可能性のある 動作を開始する命令の伝送には適していません。¶

0-RTTアプリケーションデータを含む簡略化されたTLSハンドシェイクを図2に示します。¶

    クライアント                                         サーバー

    ClientHello
   (0-RTTアプリケーションデータ) -------->
                                                  ServerHello
                                         {EncryptedExtensions}
                                                    {Finished}
                             <-------- [アプリケーションデータ]
   {Finished}                -------->

   [アプリケーションデータ]  <-------> [アプリケーションデータ]

    () はEarly Data（0-RTT）鍵で保護されたメッセージを示す
    {} はHandshake鍵を使用して保護されたメッセージを示す
    [] はApplication Data
       （1-RTT）鍵を使用して保護されたメッセージを示す

図2では、QUICで使用されないEndOfEarlyData メッセージを省略しています。 セクション8.3を参照してください。同様に、ChangeCipherSpecメッセージも KeyUpdateメッセージも QUICでは使用されません。ChangeCipherSpecはTLS 1.3では冗長です。セクション8.4を参照してください。 QUICには独自の鍵更新メカニズムがあります。セクション6を参照してください。¶

データは、複数の暗号化レベルを使用して保護されます。¶

• Initial鍵¶
• Early Data（0-RTT）鍵¶
• Handshake鍵¶
• Application Data（1-RTT）鍵¶

アプリケーションデータは、Early DataレベルとApplication Data レベルにのみ現れることができます。ハンドシェイクメッセージとアラートメッセージは、どのレベルにも現れることができます。¶

0-RTTハンドシェイクは、クライアントとサーバーが以前に 通信したことがある場合に使用できます。1-RTTハンドシェイクでは、クライアントは サーバーから送信されたすべてのハンドシェイクメッセージを受信するまで、保護された アプリケーションデータを送信できません。¶

4.1. TLSへのインターフェイス

図4に示すように、QUICからTLSへのインターフェイスは、 4つの主要な機能で構成されます。¶

• ハンドシェイクメッセージの送受信¶
• 再開されたセッションから保存済みのトランスポートおよびアプリケーション状態を 処理し、0-RTTデータを生成または受け入れることが有効かどうかを判断すること¶
• 鍵の再生成（送信と受信の両方）¶
• ハンドシェイク状態の更新¶

TLSを構成するために追加の機能が必要になる場合があります。特に、QUICと TLSは、証明書の検証[RFC5280]など、 ピア資格情報の検証をどちらが担当するかについて合意する必要があります。¶

クライアント                                              サーバー
============                                              ======

ハンドシェイク取得
                     Initial ------------->
送信0-RTT鍵をインストール
                     0-RTT - - - - - - - ->

                                          ハンドシェイク受信
                                             ハンドシェイク取得
                     <------------- Initial
                                      受信0-RTT鍵をインストール
                                 Handshake鍵をインストール
                                             ハンドシェイク取得
                     <----------- Handshake
                                     送信1-RTT鍵をインストール
                     <- - - - - - - - 1-RTT

ハンドシェイク受信（Initial）
Handshake鍵をインストール
ハンドシェイク受信（Handshake）
ハンドシェイク取得
                     Handshake ----------->
ハンドシェイク完了
1-RTT鍵をインストール
                     1-RTT - - - - - - - ->

                                          ハンドシェイク受信
                                          ハンドシェイク完了
                                          ハンドシェイク確認済み
                                     受信1-RTT鍵をインストール
                     <--------------- 1-RTT
                           (HANDSHAKE_DONE)
ハンドシェイク確認済み

4.2. TLSバージョン

この文書では、TLS 1.3 [TLS13]をQUICとともに使用する方法について説明します。¶

実際には、TLSハンドシェイクによって使用するTLSのバージョンがネゴシエートされます。 両方のエンドポイントが対応している場合、TLS 1.3より新しいバージョンのTLSが ネゴシエートされる可能性があります。QUICが使用するTLS 1.3の機能が 新しいバージョンでもサポートされている限り、これは許容されます。¶

クライアントはTLS 1.3より古いTLSバージョンを提示してはMUST NOT。 誤って構成されたTLS 実装では、TLS 1.2または別の古いTLSバージョンがネゴシエートされる可能性があります。 TLS 1.3より古いTLSバージョンがネゴシエートされた場合、エンドポイントは 接続を終了MUST。¶

4.3. ClientHelloのサイズ

クライアントからの最初のInitialパケットには、その最初の 暗号学的ハンドシェイクメッセージの先頭または全体が含まれます。TLSの場合、これはClientHelloです。サーバーは、 新しい着信QUIC接続を受け入れるかどうかを判断するために、 ClientHello全体を解析する必要がある場合があります（たとえば、 Server Name Identification (SNI)やApplication-Layer Protocol Negotiation (ALPN)などの拡張へアクセスするため）。 ClientHelloが複数のInitialパケットにまたがる場合、そのようなサーバーは 最初に受信した断片をバッファリングする必要があり、クライアントのアドレスがまだ検証されていない場合には 過剰なリソースを消費する可能性があります。これを避けるため、サーバーは、 検証済みアドレスを持つクライアントからの 部分的なClientHelloメッセージだけをバッファリングするよう、Retry機能（ [QUIC-TRANSPORT]のセクション8.1を参照）を使用するMAY。¶

QUICパケットおよびフレーミングは、ClientHello メッセージに少なくとも36バイトのオーバーヘッドを追加します。クライアントが0バイトより長いSource Connection ID フィールドを選択した場合、このオーバーヘッドは増加します。オーバーヘッドには、トークンや 8バイトより長いDestination Connection IDも含まれていません。これらはいずれも、 サーバーがRetryパケットを送信する場合に必要になる可能性があります。¶

典型的なTLS ClientHelloは、1200バイトのパケットに容易に収まります。ただし、 QUICによって追加されるオーバーヘッドに加えて、この制限を 超える可能性のある変数がいくつかあります。大きなセッションチケット、複数または大きな鍵 共有、およびサポートされる暗号、署名アルゴリズム、バージョン、 QUICトランスポートパラメーター、その他のネゴシエート可能なパラメーターや拡張の長いリストによって、 このメッセージが大きくなる可能性があります。¶

サーバーについては、接続IDおよびトークンに加えて、TLSセッション チケットのサイズもクライアントが効率的に接続できるかどうかに影響します。 これらの値のサイズを最小化すると、クライアントがそれらを使用しながら ClientHelloメッセージ全体を最初のInitial パケットに収められる可能性が高まります。¶

TLS実装は、Initialパケットを伝送するデータグラムに対する QUICの要件を満たすほどClientHelloが大きいことを保証する必要はありません。 [QUIC-TRANSPORT]のセクション14.1を参照してください。QUIC 実装はPADDINGフレームまたは パケット結合を使用して、データグラムが十分に大きくなるようにします。¶

4.4. ピア認証

認証の要件は、 使用されているアプリケーションプロトコルによって異なります。TLSはサーバー認証を提供し、サーバーが クライアント認証を要求することを許可します。¶

クライアントはサーバーのIDを認証MUST。通常、これには、 サーバーのIDが証明書に含まれており、 その証明書が信頼されたエンティティによって発行されていることの検証が含まれます（たとえば [RFC2818]を参照）。¶

サーバーは、ハンドシェイク中にクライアントへ認証を要求するMAY。 要求されたときにクライアントが認証できない場合、サーバーは 接続を拒否するMAY。 クライアント認証の要件は、アプリケーションプロトコル およびデプロイメントによって異なります。¶

サーバーは、ハンドシェイク後のクライアント 認証（[TLS13]のセクション4.6.2で定義）を使用してはMUST NOT。これは、QUICが提供する多重化により、 クライアントが証明書要求と、それを引き起こしたアプリケーションレベルの イベントを関連付けられないためです（[HTTP2-TLS13]を参照）。より具体的には、 サーバーはハンドシェイク後にTLS CertificateRequestメッセージを送信してはMUST NOT。 また、 クライアントはそのようなメッセージの受信を PROTOCOL_VIOLATIONタイプの接続エラーとして扱うMUST。¶

4.5. セッション再開

QUICはTLS 1.3のセッション再開機能を使用できます。これは、 ハンドシェイクの完了後にCRYPTOフレームでNewSessionTicketメッセージを 伝送することで行われます。セッション再開は0-RTTを提供するために使用でき、 0-RTTが無効な場合にも使用できます。¶

セッション再開を使用するエンドポイントは、再開された接続を作成するときに 現在の接続に関する一部の情報を記憶しておく必要がある場合があります。TLSでは、 一部の情報を保持する必要があります。 [TLS13]のセクション4.6.1を参照してください。QUIC自体は、 0-RTTも使用される場合を除き、接続再開時に状態が保持されることには 依存しません。[QUIC-TRANSPORT]のセクション7.4.1および セクション4.6.1を参照してください。アプリケーションプロトコルは、 再開された接続間で保持される状態に依存する場合があります。¶

クライアントは、再開に必要な任意の状態をセッション チケットとともに保存できます。サーバーは、状態の伝送を補助するためにセッションチケットを使用できます。¶

セッション再開により、サーバーは元の接続上の活動と 再開された接続を関連付けることができます。これはクライアントにとってプライバシー上の問題となる可能性があります。 クライアントは、この相関を作らないために再開を有効にしないことを選択できます。 クライアントはチケットを再利用するべきではSHOULD NOT。再利用するとサーバー以外のエンティティが 接続を関連付けられるためです。 [TLS13]の付録C.4を参照してください。¶

4.6. 0-RTT

QUICの0-RTT機能により、クライアントは ハンドシェイクが完了する前にアプリケーションデータを送信できます。これは、 以前の接続でネゴシエートされたパラメーターを再利用することで可能になります。これを有効にするため、0-RTTは クライアントが重要なパラメーターを記憶し、サーバーが同じ情報を 復元できるTLSセッションチケットをサーバーへ提供することに依存します。¶

この情報には、[TLS13]によって規定されるTLS状態を決定するパラメーター、QUICトランスポートパラメーター、 選択されたアプリケーションプロトコル、および アプリケーションプロトコルが必要とする可能性のある任意の情報が含まれます。セクション 4.6.3を参照してください。この 情報によって、0-RTTパケットとその内容がどのように形成されるかが決まります。¶

両方のエンドポイントで同じ情報を利用できるようにするため、 0-RTTの確立に使用されるすべての情報は同一の接続から取得されます。エンドポイントは、 0-RTTの送信または処理を変更する可能性がある情報を 選択的に無視することはできません。¶

[TLS13]は、元の 接続から0-RTTを使用しようとするまでの期間に7日間の制限を設けています。0-RTTの 使用には他にも制約があり、特にリプレイ攻撃にさらされる可能性による制約があります。 セクション9.2を参照してください。¶

4.7. HelloRetryRequest

HelloRetryRequestメッセージ（ [TLS13]のセクション4.1.4を参照）は、 クライアントに鍵共有などの新しい情報を提供するよう要求したり、 クライアントの特性を検証したりするために使用できます。QUICの観点では、 HelloRetryRequestはInitialパケットで伝送される他の暗号学的ハンドシェイク メッセージと区別されません。原理上は この機能をアドレス検証に使用できますが、QUIC実装は 代わりにRetry機能を使用するSHOULD。 [QUIC-TRANSPORT]のセクション8.1を参照してください。¶

4.8. TLSエラー

TLSでエラーが発生した場合、 [TLS13]のセクション6で定義されている適切なアラートを生成します。¶

TLSアラートはQUIC接続エラーに変換されます。AlertDescription 値に 0x0100を加えて、CRYPTO_ERROR用に予約された範囲のQUICエラーコードを生成します。 [QUIC-TRANSPORT]のセクション20.1を参照してください。生成された値は、 タイプ0x1cのQUIC CONNECTION_CLOSEフレームで送信されます。¶

QUICが伝達できるアラートレベルは「fatal」のみです。TLS 1.3では、 「warning」レベルの既存の用途は接続終了を通知することだけです。 [TLS13]のセクション6.1を参照してください。QUICは 接続終了のための別のメカニズムを提供しており、TLS接続はエラーが 発生した場合にのみ閉じられるため、QUICエンドポイントはTLSからの任意のアラートを 「fatal」レベルであるかのように扱うMUST。¶

QUICでは、特定のエラーコードの代わりに汎用コードを使用できます。 [QUIC-TRANSPORT]のセクション11を参照してください。TLSアラートの場合、これには任意の アラートをhandshake_failure（QUICでは0x0128）などの汎用アラートに置き換えることが含まれます。 エンドポイントは、機密 情報が露出する可能性を避けるために汎用エラーコードを使用するMAY。¶

4.9. 未使用の鍵の破棄

QUICが新しい暗号化レベルへの移行を完了すると、以前の暗号化レベル用の パケット保護鍵を破棄できます。これは ハンドシェイク中に数回発生し、鍵の更新時にも発生します。セクション6を参照してください。¶

新しい鍵が 利用可能になっても、パケット保護鍵は直ちには破棄されません。低い暗号化レベルのパケットにCRYPTOフレームが含まれている場合、 そのデータを再送するフレームは同じ暗号化 レベルで送信MUST。 同様に、エンドポイントは確認対象のパケットと同じ 暗号化レベルでパケットの確認応答を生成します。したがって、 新しい暗号化レベル用の鍵が利用可能になった後も、短時間は低い暗号化レベル用の鍵が 必要になる可能性があります。¶

エンドポイントは、特定の暗号化レベルについて、 その暗号化レベルのピアからすべての暗号学的ハンドシェイクメッセージを受信し、 ピアも同様に受信したことが確認できるまで鍵を破棄できません。これを判定するために、 Initial鍵（セクション4.9.1）と Handshake鍵（セクション4.9.2）には異なる方法が用意されています。これらの方法は、 ピアが必要な確認応答をすべて受信していない可能性があるため、 その暗号化レベルでのパケットの受信または送信を防ぐものではありません。¶

エンドポイントが古い鍵を保持している場合でも、新しいデータは、 現在利用可能な最も高い暗号化レベルで送信MUST。 以前の暗号化レベルでは、ACKフレームと CRYPTOフレーム内のデータの再送のみが送信されます。これらのパケットには PADDINGフレームを含めるMAY。¶

5.1. パケット保護鍵

QUICは、TLSがレコード 保護鍵を導出するのと同じ方法でパケット保護鍵を導出します。¶

各暗号化レベルには、それぞれの方向に送信されるパケットを保護するための 個別のシークレット値があります。これらのトラフィックシークレットはTLSによって導出され（ [TLS13]のセクション7.1を参照）、 Initial 暗号化レベルを除くすべての暗号化レベルでQUICによって使用されます。Initial暗号化レベル用のシークレットは、 セクション5.2で説明するように、クライアントの初期Destination Connection IDに 基づいて計算されます。¶

パケット保護に使用される鍵は、TLSが提供する KDFを使用してTLSシークレットから計算されます。TLS 1.3では、 [TLS13]のセクション7.1で説明されているHKDF-Expand-Label関数を、 ネゴシエートされた暗号スイートのハッシュ 関数とともに使用します。QUICにおけるHKDF-Expand-Labelのすべての使用では、長さ0のContextを使用します。¶

文字列として記述されるラベルは、 引用符や末尾のNUL バイトを付けず、ASCII[ASCII]を使用してバイトとしてエンコードされることに注意してください。¶

他のTLSバージョンは、QUICとともに 使用できるようにするため、同様の関数を提供MUST。¶

現在の暗号化レベルのシークレットとラベル"quic key"を KDFへの入力としてAEAD鍵を生成します。ラベル"quic iv"は Initialization Vector (IV)の導出に使用されます。セクション5.3を参照してください。ヘッダー 保護鍵には "quic hp"ラベルを使用します。セクション5.4を参照してください。これらのラベルを使用することで、 QUICとTLSの間で鍵を分離できます。セクション9.6を参照してください。¶

"quic key"と"quic hp"はいずれも鍵の生成に使用されるため、 これらのラベルとともにHKDF-Expand-Labelへ与えられるLengthは、 AEADまたはヘッダー保護アルゴリズムの鍵サイズによって決まります。"quic iv"とともに与えられるLengthは、 AEAD nonceの最小長、またはそれより大きい場合は8バイトです。 [AEAD]を参照してください。¶

Initialシークレットに使用するKDFは、常に TLS 1.3のHKDF-Expand-Label関数です。セクション5.2を参照してください。¶

5.2. Initialシークレット

Initialパケットにはパケット保護処理を適用しますが、 クライアントの最初のInitial パケットのDestination Connection IDフィールドから導出したシークレットを使用します。¶

このシークレットは、ソルトとして0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a、 入力鍵素材（IKM）としてDestination Connection IDフィールドを使用して HKDF-Extract（ [HKDF]のセクション2.2を参照）を実行することで決定されます。これにより、 送信用と受信用の2つの別個のシークレットを導出するために使用される 中間擬似乱数鍵（PRK）が生成されます。¶

クライアントがInitialパケットを構築するために使用するシークレットは、 TLSのHKDF-Expand-Label関数にPRKと ラベル"client in"を入力し、 [TLS13]に従って32バイトのシークレットを生成します。サーバーが構築するパケットでは、 ラベル"server in"を使用して同じ処理を行います。Initialシークレットおよび鍵を 導出する際のHKDFのハッシュ関数はSHA-256 [SHA]です。¶

この処理を擬似コードで表すと次のようになります。¶

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

HKDF-Expand-Labelで使用される接続IDは、クライアントが送信したInitialパケット内の Destination Connection IDです。クライアントがRetry パケットの受信後にInitialパケットを作成する場合を除き、これはランダムに選択された 値になります。Retryパケットの受信後は、Destination Connection IDはサーバーによって選択されます。¶

将来のQUICバージョンでは新しいソルト 値を生成し、それによってQUICの各バージョンで 鍵が異なることを保証するSHOULD。これにより、1つのQUICバージョンだけを認識するミドルボックスが、 将来のバージョンのパケット内容を閲覧または変更することを防ぎます。¶

TLS 1.3で定義されたHKDF-Expand-Label関数は、提示されるTLSバージョンに TLS 1.3が含まれていない場合でも、Initial パケットに使用MUST。¶

後続のInitialパケットを構築するために使用されるシークレットは、 サーバーがRetryパケットを送信した際に、サーバーが選択した接続ID値を使用するよう変更されます。 クライアントがサーバーからのInitialパケットへの応答として使用するDestination Connection IDを変更しても、シークレットは変更されません。¶

付録AにはInitial パケットの例が含まれています。¶

5.3. AEADの使用

QUICパケット保護に使用されるAuthenticated Encryption with Associated Data (AEAD)関数（[AEAD]を参照）は、 TLS接続で使用するためにネゴシエートされたAEADです。たとえば、TLSが TLS_AES_128_GCM_SHA256暗号スイートを使用している場合、AEAD_AES_128_GCM関数を使用します。¶

QUICは、TLS_AES_128_CCM_8_SHA256を除き、 [TLS13]で定義されている任意の暗号スイートを使用できます。 暗号スイートに対するヘッダー保護方式が定義されていない限り、 その暗号スイートをネゴシエートしてはMUST NOT。 この文書では、TLS_AES_128_CCM_8_SHA256を除く [TLS13]で定義されているすべての暗号スイートに対するヘッダー保護方式を定義します。 これらの暗号スイートは16バイトの 認証タグを持ち、入力より16バイト大きい出力を生成します。¶

エンドポイントは、 サポートしていない暗号スイートを提示するClientHelloを拒否してはMUST NOT。 そうすると新しい暗号スイートをデプロイできなくなるためです。これは TLS_AES_128_CCM_8_SHA256にも適用されます。¶

パケットを構築する際、AEAD関数は ヘッダー保護を適用する前に適用されます。セクション5.4を参照してください。保護されていない パケットヘッダーはassociated data (A)の一部です。パケットを処理する際、 エンドポイントは最初にヘッダー保護を解除します。¶

パケット用の鍵とIVは、セクション5.1で説明するように計算されます。 nonce Nは、パケット保護IVとパケット 番号を組み合わせて形成されます。再構築されたQUICパケット番号の62ビットは、ネットワークバイト オーダーで、IVのサイズになるまで左側をゼロで埋めます。パディングされた パケット番号とIVの排他的ORによってAEAD nonceが形成されます。¶

AEADのassociated data Aは、QUICヘッダーの内容であり、 ショートヘッダーまたはロングヘッダーの最初のバイトから始まり、 保護されていないパケット番号を含む位置までです。¶

AEADへの入力平文Pは、 [QUIC-TRANSPORT]で説明されているQUICパケットのペイロードです。¶

AEADの出力暗号文Cは、Pの代わりに送信されます。¶

一部のAEAD関数には、同じ鍵とIVで 暗号化できるパケット数に制限があります。セクション6.6を参照してください。これはパケット 番号の上限より低い場合があります。エンドポイントは、使用中のAEADに設定された 制限を超える前に鍵更新（セクション6）を開始MUST。¶

5.4. ヘッダー保護

QUICパケットヘッダーの一部、特にPacket Numberフィールドは、 パケット保護鍵およびIVとは別に導出された鍵を使用して 保護されます。"quic hp"ラベルを使用して導出された鍵は、 経路上の要素に公開されないフィールドに 機密性保護を提供するために使用されます。¶

この保護は、最初のバイトの最下位ビットと Packet Numberフィールドに適用されます。ロングヘッダーを持つパケットでは最初のバイトの最下位4ビットが 保護され、ショートヘッダーを持つパケットでは最初のバイトの最下位5ビットが保護されます。どちらのヘッダー形式でも、 これには予約ビットとPacket Number Lengthフィールドが含まれます。ショートヘッダーを持つパケットでは Key Phaseビットも保護されます。¶

同じヘッダー保護鍵が接続の存続期間中使用され、 鍵更新後も値は変更されません（セクション6を参照）。これにより、 鍵フェーズを保護するためにヘッダー保護を使用できます。¶

この処理はRetryまたはVersion Negotiationパケットには適用されません。これらには、 保護されたペイロードも、この 処理によって保護されるフィールドも含まれていないためです。¶

mask = header_protection(hp_key, sample)

pn_length = (packet[0] & 0x03) + 1
if (packet[0] & 0x80) == 0x80:
   # ロングヘッダー: 4ビットをマスク
   packet[0] ^= mask[0] & 0x0f
else:
   # ショートヘッダー: 5ビットをマスク
   packet[0] ^= mask[0] & 0x1f

# pn_offsetはPacket Numberフィールドの開始位置。
packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]

Initial Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 0,
  Reserved Bits (2),         # 保護対象
  Packet Number Length (2),  # 保護対象
  Version (32),
  DCID Len (8),
  Destination Connection ID (0..160),
  SCID Len (8),
  Source Connection ID (0..160),
  Token Length (i),
  Token (..),
  Length (i),
  Packet Number (8..32),     # 保護対象
  Protected Payload (0..24), # スキップする部分
  Protected Payload (128),   # サンプリングする部分
  Protected Payload (..)     # 残り
}

1-RTT Packet {
  Header Form (1) = 0,
  Fixed Bit (1) = 1,
  Spin Bit (1),
  Reserved Bits (2),         # 保護対象
  Key Phase (1),             # 保護対象
  Packet Number Length (2),  # 保護対象
  Destination Connection ID (0..160),
  Packet Number (8..32),     # 保護対象
  Protected Payload (0..24), # スキップする部分
  Protected Payload (128),   # サンプリングする部分
  Protected Payload (..),    # 残り
}

# pn_offsetはPacket Numberフィールドの開始位置。
sample_offset = pn_offset + 4

sample = packet[sample_offset..sample_offset+sample_length]

pn_offset = 1 + len(connection_id)

pn_offset = 7 + len(destination_connection_id) +
                len(source_connection_id) +
                len(payload_length)
if packet_type == Initial:
    pn_offset += len(token_length) +
                 len(token)

header_protection(hp_key, sample):
  mask = AES-ECB(hp_key, sample)

header_protection(hp_key, sample):
  counter = sample[0..3]
  nonce = sample[4..15]
  mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})

5.5. 保護された パケットの受信

エンドポイントが特定のパケット番号を持つパケットを正常に受信した後、 同じパケット番号空間でより大きなパケット 番号を持つパケットが、同じ鍵、または 鍵更新がある場合には後続のパケット保護鍵のいずれを使用しても正常に保護解除できない場合、 それらをすべて破棄MUST。セクション6を参照してください。同様に、鍵更新を引き起こすように見えるが、 正常に保護解除できないパケットも破棄MUST。¶

パケットの保護解除に失敗しても、必ずしも ピアのプロトコルエラーまたは攻撃の存在を示すわけではありません。QUICで使用される切り詰められたパケット番号 エンコードでは、パケットが大幅に遅延した場合に パケット番号が誤ってデコードされる可能性があります。¶

5.6. 0-RTT鍵の使用

0-RTT鍵が利用可能な場合（セクション 4.6.1を参照）、リプレイ保護がないため、 プロトコルへのリプレイ攻撃を避けるためにその使用を制限する必要があります。¶

[QUIC-TRANSPORT]で定義されているフレームのうち、STREAM、RESET_STREAM、 STOP_SENDING、およびCONNECTION_CLOSEフレームは、アプリケーションデータを伝送するため、 0-RTTで使用するには潜在的に安全ではありません。0-RTTで受信したアプリケーションデータにより、 サーバー上のアプリケーションがデータを1回ではなく複数回 処理する可能性があります。リプレイされたアプリケーションデータの処理によってサーバーが行う追加の動作は、 望ましくない結果を引き起こす可能性があります。したがってクライアントは、使用中のアプリケーションから 明示的に要求されない限り、アプリケーションデータに0-RTTを使用してはMUST NOT。¶

QUICを使用するアプリケーションプロトコルは、 0-RTTの許容される使用方法を定義するプロファイルを含めるMUST。そうでなければ、0-RTTは アプリケーションデータを伝送しないQUICフレームの伝送にのみ使用できます。たとえば、HTTP用のプロファイルは [HTTP-REPLAY]で説明され、HTTP/3で使用されます。 [QUIC-HTTP]のセクション10.9を参照してください。¶

パケットのリプレイによって追加の接続試行が生じる可能性がありますが、 アプリケーションデータを伝送しないリプレイされたフレームを処理する影響は、 影響を受ける接続の状態を変更することに限られます。TLSハンドシェイクは、 リプレイされたパケットを使用して正常に完了することはできません。¶

クライアントは、TLSハンドシェイクが完了する前に送信するデータに 追加の制限を適用したい場合があります。¶

それ以外の場合、クライアントは0-RTT鍵を1-RTT鍵と同等に扱います。ただし、 0-RTT鍵では特定のフレームを送信できません。 [QUIC-TRANSPORT]のセクション12.5を参照してください。¶

0-RTTデータがサーバーに受け入れられたという通知を受けたクライアントは、 サーバーのすべてのハンドシェイク メッセージを受信するまで0-RTTデータを送信できます。0-RTTデータが拒否されたという通知を受けた場合、 クライアントは0-RTTデータの送信を停止するSHOULD。¶

サーバーはパケットを保護するために0-RTT鍵を使用してはMUST NOT。 0-RTTパケットへの確認応答を 保護するためには1-RTT鍵を使用します。クライアントは受信した 0-RTTパケットを復号しようとしてはMUST NOT、代わりにそれらを破棄MUST。¶

クライアントが1-RTT鍵をインストールした後は、それ以上 0-RTTパケットを送信してはMUST NOT。¶

5.7. 順不同で到着した 保護パケットの受信

並べ替えや損失により、最終的なTLSハンドシェイクメッセージを受信する前に、 保護されたパケットをエンドポイントが受信する可能性があります。クライアントは サーバーからの1-RTTパケットを復号できませんが、サーバーは クライアントからの1-RTTパケットを復号できます。どちらの役割のエンドポイントも、 ハンドシェイクを完了する前にピアからの1-RTTパケットを復号してはMUST NOT。¶

サーバーはクライアントから最初の ハンドシェイクメッセージを受信した後に1-RTT鍵を利用できますが、クライアントの状態に関する保証が不足しています。¶

• サーバーが 事前共有鍵を使用することを選択し、クライアントの事前共有鍵binderを検証していない限り、クライアントは認証されていません。 [TLS13]のセクション4.2.11を参照してください。¶
• サーバーがRetryパケットまたはその他の手段で クライアントのアドレスを検証していない限り、クライアントは稼働性を実証していません。 [QUIC-TRANSPORT]のセクション8.1を参照してください。¶
• サーバーが応答する受信済み0-RTTデータは、 リプレイ攻撃によるものである可能性があります。¶

したがって、ハンドシェイクが完了する前にサーバーが1-RTT鍵を使用できるのは、 データの送信に限られます。サーバーは、TLSハンドシェイクが完了する前に受信した 1-RTT保護パケットを処理してはMUST NOT。 確認応答を送信することはパケット内のすべてのフレームが処理済みであることを示すため、サーバーは TLSハンドシェイクが完了するまで1-RTTパケットへの確認応答を送信できません。 1-RTT鍵で保護された受信パケットは保存し、 ハンドシェイク完了後に復号して使用するMAY。¶

サーバーがクライアントのFinishedメッセージを待つという要件により、 そのメッセージが配信されることへの依存が生じます。クライアントは、 Finishedメッセージを伝送するCRYPTOフレームのコピーを含むHandshakeパケットと 1-RTTパケットを結合して送信し、いずれかのHandshakeパケットが 確認応答されるまで続けることで、これによって生じ得るhead-of-line blockingを回避できます。 これにより、サーバーはそれらのパケットを直ちに処理できます。¶

サーバーは、TLS ClientHelloを受信する前に0-RTT鍵で保護されたパケットを 受信する可能性があります。サーバーは、 ClientHelloを受信することを見越して、後で復号するためにこれらのパケットを保持するMAY。¶

クライアントは通常、ハンドシェイクが 完了するのと同時に1-RTT鍵を受け取ります。1-RTTシークレットを持っていたとしても、クライアントは TLSハンドシェイクが完了する前に受信した1-RTT保護パケットを処理してはMUST NOT。¶

5.8. Retryパケットの完全性

Retryパケット（ [QUIC-TRANSPORT]のセクション17.2.5を参照）は、 2つの特性を提供するRetry Integrity Tagを伝送します。これは、ネットワークによって 偶発的に破損したパケットを破棄できるようにし、Initialパケットを観測したエンティティだけが 有効なRetryパケットを送信できるようにします。¶

Retry Integrity Tagは、次の入力を使用した AEAD_AES_128_GCM[AEAD]の出力として計算される128ビットのフィールドです。¶

• シークレット鍵Kは128ビットで、 0xbe0c690b9f66575a1d766b54e368c84eに等しい値です。¶
• nonce Nは96ビットで、 0x461599d35d632bf2239825bbに等しい値です。¶
• 平文Pは空です。¶
• associated data Aは、 図8に示すRetry Pseudo-Packetの内容です。¶

シークレット鍵とnonceは、 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8eを シークレットとして、ラベル"quic key"と"quic iv"を使用してHKDF-Expand-Labelを呼び出すことで導出されます （セクション5.1）。¶

Retry Pseudo-Packet {
  ODCID Length (8),
  Original Destination Connection ID (0..160),
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 3,
  Unused (4),
  Version (32),
  DCID Len (8),
  Destination Connection ID (0..160),
  SCID Len (8),
  Source Connection ID (0..160),
  Retry Token (..),
}

Retry Pseudo-Packetはネットワーク上には送信されません。送信された RetryパケットからRetry Integrity Tagを除去し、 次の2つのフィールドを先頭に付加することで計算されます。¶

ODCID Length:

ODCID Lengthフィールドには、その後に続く Original Destination Connection IDフィールドの長さをバイト単位で格納し、8ビットの符号なし 整数としてエンコードします。¶

Original Destination Connection ID:

Original Destination Connection IDには、このRetryが応答しているInitialパケットの Destination Connection IDの値が格納されます。この フィールドの長さはODCID Lengthによって指定されます。このフィールドが存在することにより、 Initialパケットを観測したエンティティだけが有効なRetryパケットを送信できることが 保証されます。¶

6.1. 鍵の更新の 開始

エンドポイントは、パケット保護用に個別の読み取りシークレットと書き込みシークレットを保持します。 エンドポイントは、パケット保護用の書き込みシークレットを更新し、 それを新しいパケットの保護に使用することで鍵の更新を開始します。エンドポイントは、 [TLS13]のセクション7.2で行われるのと同様に、 既存の書き込みシークレットから新しい書き込みシークレットを作成します。これには、 TLSによって提供されるKDF関数を"quic ku"というラベルとともに使用します。対応する 鍵とIVは、セクション5.1で定義されるように、そのシークレットから作成されます。 ヘッダー保護鍵は更新されません。¶

たとえば、TLS 1.3で書き込み鍵を更新するには、HKDF-Expand-Labelを 次のように使用します。¶

secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
                                 "", Hash.length)

エンドポイントはKey Phaseビットの値を切り替え、更新された鍵と IVを使用して、その後のすべてのパケットを保護します。¶

エンドポイントは、ハンドシェイクを確認する前に 鍵の更新を開始してはMUST NOT（セクション4.1.2）。 エンドポイントは、現在の鍵フェーズの鍵で保護して送信されたパケットに対する 確認応答を受信していない限り、後続の 鍵更新を開始してはMUST NOT。これにより、次の鍵更新を開始する前に、 両方のピアで鍵が利用可能であることが保証されます。これは、 各鍵フェーズで送信した最小のパケット番号と、 1-RTT空間で確認応答された最大のパケット番号を追跡することで実装できます。後者が 前者以上になれば、次の鍵更新を開始できます。¶

鍵更新を開始するエンドポイントは、 パケットの受信に使用する鍵も更新します。これらの鍵は、 ピアが更新後に送信するパケットを処理するために必要になります。¶

エンドポイントは、新しい鍵を使用して送信されたパケットの保護を 正常に解除するまで古い鍵を保持MUST。 エンドポイントは、新しい鍵を使用して送信されたパケットの保護を解除した後も、 しばらくの間古い鍵を保持するSHOULD。 古い鍵を早く破棄しすぎると、遅延したパケットが破棄される可能性があります。パケットの破棄は ピアによってパケット損失として解釈され、性能に悪影響を及ぼす可能性があります。¶

6.2. 鍵の更新への 応答

ピアは、現在の鍵フェーズのパケットに対する確認応答を受信した後、 鍵の更新を開始できます。エンドポイントは、 最後に送信したパケットの保護に使用した値とは異なる鍵フェーズを持つパケットを 処理するときに鍵更新を検出します。このパケットを処理するため、エンドポイントは次の パケット保護鍵とIVを使用します。これらの鍵を生成する際の考慮事項については、 セクション6.3を参照してください。¶

次の鍵とIVを使用してパケットが正常に処理された場合、ピアが 鍵更新を開始したことになります。エンドポイントは、応答として送信鍵を 対応する鍵フェーズへ更新MUST。これはセクション6.1で説明されています。 送信鍵は、更新された鍵で受信したパケットに対する確認応答を 送信する前に更新MUST。 鍵更新を引き起こしたパケットを、更新された鍵で保護されたパケット内で確認応答することで、 エンドポイントは鍵更新が完了したことを通知します。¶

エンドポイントは、通常のパケット送信動作に従ってパケットまたは確認応答の送信を 遅らせることができます。鍵更新に応答して直ちに パケットを生成する必要はありません。エンドポイントが次に送信するパケットでは 更新された鍵を使用します。確認応答を含む次のパケットによって 鍵更新が完了します。エンドポイントが、更新された鍵を使用し、 鍵更新を開始したパケットへの確認応答を含むパケットをまだ一度も送信していないうちに 2回目の更新を検出した場合、これは ピアが確認を待たずに鍵を2回更新したことを示します。エンドポイントは、 このような連続した鍵更新を KEY_UPDATE_ERRORタイプの接続エラーとして扱うMAY。¶

エンドポイントが、古い鍵で保護されたパケットに含まれる確認応答を受信し、 その確認対象パケットのいずれかが新しい 鍵で保護されていた場合、これをKEY_UPDATE_ERRORタイプの接続エラーとして扱うMAY。 これは、ピアが鍵更新を開始するパケットを受信して確認応答したものの、 応答として鍵を更新していないことを示します。¶

6.3. 受信鍵 生成のタイミング

見かけ上の鍵更新に応答するエンドポイントは、 Key Phaseビットが無効であったことを示す可能性があるタイミング サイドチャネル信号を生成してはMUST NOT（セクション9.5を参照）。 鍵更新がまだ許可されていない場合、エンドポイントは破棄された鍵の代わりに ランダム化されたパケット保護鍵を使用できます。 ランダム化された鍵を使用することで、パケット保護の解除を試みても タイミングのばらつきが生じないことが保証され、無効なKey Phase ビットを持つパケットは拒否されます。¶

パケット受信用に新しいパケット保護鍵を作成する処理によって、 鍵更新が発生したことが明らかになる可能性があります。エンドポイントは、パケット処理の 一部として新しい鍵を生成するMAYが、これは攻撃者が 鍵更新がいつ発生するかを知るために利用できるタイミング信号を生み出し、その結果 Key Phaseビットの値が漏れる可能性があります。¶

一般に、エンドポイントは現在および次の受信パケット 保護鍵を利用可能にしておくことが期待されます。鍵更新が完了した後の短い期間、 最大PTOまで、エンドポイントは次の 受信パケット保護鍵セットの生成を遅らせるMAY。 これにより、エンドポイントは 受信鍵を2セットだけ保持できます。セクション6.5を参照してください。¶

一度生成された次のパケット保護鍵セットは、 受信したパケットが後で破棄された場合でも保持するSHOULD。 見かけ上の鍵更新を含むパケットは容易に偽造できます。鍵更新処理自体は 大きな労力を必要としませんが、この処理を引き起こすことは 攻撃者によるDoSに利用される可能性があります。¶

このため、エンドポイントは、パケット受信用に 現在および次の2セットのパケット保護 鍵を保持できるMUST。 これらに加えて以前の鍵を保持すると性能が向上する可能性がありますが、必須ではありません。¶

6.4. 更新された鍵による 送信

エンドポイントは、古い鍵で保護されたパケットを送信することはありません。 現在の鍵だけが使用されます。パケット保護に使用した鍵は、 新しい鍵へ切り替えた直後に破棄できます。¶

より大きなパケット番号を持つパケットは、より小さなパケット番号を持つパケットと 同じか、それより新しいパケット保護鍵で 保護MUST。 より小さなパケット番号を持つパケットに新しい鍵が使用されていたにもかかわらず、 古い鍵で正常に保護を解除したエンドポイントは、これを KEY_UPDATE_ERRORタイプの接続エラーとして扱うMUST。¶

6.5. 異なる鍵による 受信

鍵更新中にパケットを受信する際、古い鍵で保護されたパケットが ネットワークで遅延したために到着する可能性があります。古いパケット 保護鍵を保持しておくことで、これらのパケットを正常に処理できます。¶

次の鍵フェーズの鍵で保護されたパケットは、 以前の鍵フェーズの鍵で保護されたパケットと同じKey Phase 値を使用するため、古い鍵で保護されたパケットを処理する場合には、 両者を区別する必要があります。これはパケット番号を使用して行えます。復元されたパケット番号が 現在の鍵フェーズのどのパケット番号よりも小さい場合は 以前のパケット保護鍵を使用し、復元されたパケット番号が 現在の鍵フェーズのどのパケット番号よりも大きい場合は、次のパケット 保護鍵を使用する必要があります。¶

以前、現在、次のパケット保護鍵から選択する 処理が、どの鍵を使用してパケット保護を解除したかを明らかにする可能性があるタイミング サイドチャネルを露出しないよう注意が必要です。詳細については、 セクション9.5を参照してください。¶

または、エンドポイントはパケット保護鍵を2セットだけ保持し、 ネットワークでの並べ替えを許容するのに十分な時間が経過した後、 以前の鍵を次の鍵と入れ替えることもできます。この場合、Key Phaseビットだけを使用して 鍵を選択できます。¶

エンドポイントは、次の受信鍵セットを現在の鍵へ昇格させた後、 後続のパケット保護鍵セットを作成するまで、 Probe Timeout（PTO。[QUIC-RECOVERY]を参照）程度の期間を 設けるMAY。 その時点で、これらの更新された 鍵は以前の鍵を置き換えるMAY。PTOは 主観的な尺度である、つまりピアがRTTについて異なる見方を持つ可能性があるという点に注意が必要ですが、 この期間は、並べ替えられたパケットが確認応答されたとしても ピアによって損失と宣言されるのに十分長く、かつ ピアが追加の鍵更新を開始できる程度には短いと想定されています。¶

エンドポイントは、ピアが古い鍵を保持している期間中、 鍵更新を開始するパケットを復号できない可能性を考慮する必要があります。 エンドポイントは、以前の鍵更新が受信されたことを確認する確認応答を受け取った後、 次の鍵更新を開始するまでPTOの3倍待つSHOULD。 十分な時間を設けないと、パケットが破棄される可能性があります。¶

エンドポイントは、新しい鍵を使用して保護されたパケットを受信した後、 PTOの3倍を超えて古い読み取り鍵を保持するべきではSHOULD。 この期間が経過した後、 古い読み取り鍵と対応するシークレットは破棄するSHOULD。¶

6.6. AEAD使用の制限

この文書では、AEADアルゴリズムの過度な使用によって、 QUIC使用時の通信の 機密性と完全性を攻撃する上で、攻撃者に不釣り合いな優位性を与えないようにするため、 使用制限を定めています。¶

TLS 1.3で定義される使用制限は、 機密性への攻撃に対する保護のために存在し、AEAD保護の適用に成功した場合に適用されます。 認証付き暗号化における完全性保護は、パケット偽造の 試行回数を制限することにも依存します。TLSでは、レコードが 認証チェックに失敗した後に接続を閉じることでこれを実現します。これに対しQUICは、 認証できないパケットをすべて無視し、複数回の偽造試行を許容します。¶

QUICは、AEADの機密性制限と完全性制限を別々に扱います。 機密性制限は、特定の 鍵で暗号化されるパケット数に適用されます。完全性制限は、 特定の接続内で復号されるパケット数に適用されます。 各AEADアルゴリズムでこれらの制限を適用する方法の詳細を以下に示します。¶

エンドポイントは、各鍵セットについて暗号化された パケット数を数えるMUST。同じ鍵で暗号化されたパケットの 総数が、選択されたAEADの機密性制限を超えた場合、エンドポイントは それらの鍵の使用を停止MUST。 エンドポイントは、選択されたAEADの機密性制限で許可される数を超える 保護パケットを送信する前に、鍵更新を開始MUST。 鍵更新が不可能な場合、または完全性制限に達した場合、エンドポイントは 接続の使用を停止MUSTし、パケット受信への応答としては stateless resetだけを送信しなければなりません。 鍵更新が不可能な状態に達する前に、 エンドポイントがAEAD_LIMIT_REACHEDタイプの接続エラーで 接続を直ちに閉じることがRECOMMENDED。¶

AEAD_AES_128_GCMおよびAEAD_AES_256_GCMでは、機密性制限は 2²³個の暗号化パケットです。付録B.1を参照してください。 AEAD_CHACHA20_POLY1305では、機密性制限は 可能なパケット数（2⁶²）より大きいため、無視できます。 AEAD_AES_128_CCMでは、機密性制限は2^21.5個の暗号化 パケットです。付録B.2を参照してください。制限を適用することで、 攻撃者が使用中のAEADとランダム置換を区別できる確率が低下します。 [AEBounds]、[ROBUST]、および[GCM-MU]を参照してください。¶

送信パケットを数えることに加えて、エンドポイントは、 接続の存続期間中に認証に失敗した 受信パケット数を数えるMUST。 すべての鍵にわたって、接続内で認証に失敗した受信パケットの 総数が、選択されたAEADの完全性制限を超えた場合、 エンドポイントはAEAD_LIMIT_REACHEDタイプの接続エラーで 接続を直ちに閉じ、それ以上パケットを処理してはMUST。¶

AEAD_AES_128_GCMおよびAEAD_AES_256_GCMでは、完全性制限は 2⁵²個の 無効なパケットです。付録B.1を参照してください。 AEAD_CHACHA20_POLY1305では、完全性 制限は2³⁶個の無効なパケットです。[AEBounds]を参照してください。AEAD_AES_128_CCMでは、 完全性制限は2^21.5個の無効なパケットです。 付録B.2を参照してください。この制限を適用することで、 攻撃者がパケットの偽造に成功する確率が低下します。[AEBounds]、 [ROBUST]、および[GCM-MU]を参照してください。¶

パケットサイズを制限するエンドポイントは、より高い機密性および 完全性制限を使用するMAY。詳細については付録Bを参照してください。¶

将来の分析および仕様では、AEADの 機密性または完全性の制限を緩和するMAY。¶

QUICで使用するよう規定される任意のTLS暗号スイートは、 機密性および完全性の余裕を維持する、 関連するAEAD関数の使用制限を定義MUST。 すなわち、認証できるパケット数と、 認証に失敗できるパケット数について制限を規定MUST。 値の根拠となる分析、およびその分析で使用した前提への参照を提供することで、 さまざまな使用条件に応じて制限を調整できます。¶

6.7. 鍵更新エラーコード

KEY_UPDATE_ERRORエラーコード（0x0e）は、鍵の 更新に関連するエラーを通知するために使用されます。¶

8.1. プロトコルネゴシエーション

QUICは、暗号学的ハンドシェイクが認証されたプロトコル ネゴシエーションを提供することを要求します。TLSはApplication-Layer Protocol Negotiation [ALPN]を使用してアプリケーションプロトコルを選択します。 アプリケーションプロトコルへの合意に別のメカニズムが 使用されない限り、エンドポイントはこの目的にALPNを使用MUST。¶

ALPNを使用する場合、アプリケーションプロトコルがネゴシエートされなければ、 エンドポイントはno_application_protocol TLSアラート（QUIC エラーコード0x0178。セクション4.8を参照）で接続を直ちに閉じるMUST （[QUIC-TRANSPORT]のセクション10.2を参照）。 [ALPN]では、このアラートを使用するのはサーバーだけと規定されていますが、 QUICクライアントは ALPNネゴシエーションが失敗した場合、エラー0x0178を使用して接続を終了MUST。¶

アプリケーションプロトコルは、動作できるQUIC バージョンを制限するMAY。 サーバーは、クライアントが選択したQUIC バージョンと互換性のあるアプリケーションプロトコルを選択MUST。 サーバーは、 互換性のあるアプリケーションプロトコルを選択できないことを タイプ0x0178（no_application_protocol）の接続エラーとして扱うMUST。 同様に、クライアントは サーバーによる互換性のないアプリケーションプロトコルの選択を タイプ0x0178の接続エラーとして扱うMUST。¶

8.2. QUICトランスポート パラメーター拡張

QUICトランスポートパラメーターはTLS拡張で伝送されます。異なる QUICバージョンでは、トランスポート構成をネゴシエートするための別の方法を定義する場合があります。¶

TLSハンドシェイクにトランスポートパラメーターを含めることで、 これらの値に完全性保護が提供されます。¶

   enum {
      quic_transport_parameters(0x39), (65535)
   } ExtensionType;

quic_transport_parameters拡張のextension_dataフィールドには、 使用中のQUICバージョンによって定義される値が含まれます。¶

quic_transport_parameters拡張は、ハンドシェイク中にClientHelloおよび EncryptedExtensionsメッセージで伝送されます。エンドポイントは quic_transport_parameters拡張を送信MUST。 quic_transport_parameters拡張を含まないClientHelloまたは EncryptedExtensionsメッセージを受信したエンドポイントは、 タイプ0x016dのエラー（fatal TLS missing_extensionアラートに相当。セクション4.8を参照）で接続を閉じるMUST。¶

トランスポートパラメーターは、ハンドシェイク完了前に利用可能になります。 サーバーは、ハンドシェイク完了前にこれらの値を使用する場合があります。ただし、 トランスポートパラメーターの値はハンドシェイクが 完了するまで認証されないため、これらのパラメーターの使用はその真正性に依存できません。 トランスポートパラメーターが改ざんされると、ハンドシェイクは失敗します。¶

エンドポイントは、QUICを使用しないTLS 接続（[TLS13]で定義されるTCPでのTLS使用など）でこの拡張を送信してはMUST NOT。 トランスポートがQUICでないときにこの拡張を受信した場合、 この拡張をサポートする実装はfatal unsupported_extensionアラートを送信MUST。¶

quic_transport_parameters拡張をネゴシエートすると、EndOfEarlyDataが 削除されます。セクション8.3を参照してください。¶

8.3. EndOfEarlyDataメッセージの削除

TLS EndOfEarlyDataメッセージはQUICでは使用されません。QUICは、 このメッセージを0-RTTデータの終端を示したり、Handshake 鍵への変更を通知したりするために使用しません。¶

クライアントはEndOfEarlyDataメッセージを送信してはMUST NOT。 サーバーは、 0-RTTパケット内のCRYPTOフレームの受信を PROTOCOL_VIOLATIONタイプの接続エラーとして扱うMUST。¶

その結果、EndOfEarlyDataはTLSハンドシェイクトランスクリプトには現れません。¶

8.4. TLSミドルボックス 互換モードの禁止

[TLS13]の付録D.4では、 一部のミドルボックスのバグを回避するための TLS 1.3ハンドシェイクの変更について説明しています。TLS 1.3ミドルボックス互換 モードでは、ClientHelloとServerHelloのlegacy_session_idフィールドを 32バイトの値に設定し、その後change_cipher_specレコードを送信します。 フィールドもレコードも意味的な内容を持たず、無視されます。¶

このモードは、TCP上のTLSに干渉するミドルボックスにのみ適用されるため、 QUICでは用途がありません。QUICにはchange_cipher_spec レコードを伝送する手段もありません。クライアントはTLS 1.3 互換モードの使用を要求してはMUST NOT。 サーバーは、空でない legacy_session_idフィールドを持つTLS ClientHelloの受信をPROTOCOL_VIOLATIONタイプの接続エラーとして扱うSHOULD。¶

9.1. セッションのリンク可能性

TLSセッションチケットを使用すると、サーバーや場合によっては他のエンティティが、 同じクライアントによって行われた接続を関連付けることができます。詳細についてはセクション 4.5を参照してください。¶

9.2. 0-RTTに対する リプレイ攻撃

[TLS13]のセクション8で説明されているように、 TLS early dataの使用にはリプレイ攻撃にさらされる危険があります。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. パケット反射攻撃の 緩和

小さなClientHelloによってサーバーから大きなハンドシェイクメッセージのブロックが 生成される場合、攻撃者が生成するトラフィックを増幅する パケット反射攻撃に利用できます。¶

QUICには、この攻撃に対する3つの防御があります。第一に、ClientHelloを含むパケットは 最小サイズまでパディングMUST。第二に、 検証されていない送信元アドレスに応答する場合、サーバーは受信したバイト数の 3倍を超えるバイトを送信することを禁止されています（ [QUIC-TRANSPORT]のセクション8.1を参照）。 最後に、Handshakeパケットへの 確認応答は認証されるため、ブラインド攻撃者はそれを偽造できません。これらの防御を 組み合わせることで、増幅の程度が制限されます。¶

9.4. ヘッダー保護の 分析

[NAN]では、nonceのプライバシーを提供する 認証付き暗号化アルゴリズムを分析しており、これらを「Hide Nonce」(HN) 変換と呼びます。この文書の一般的なヘッダー保護構成は、 それらのアルゴリズムの1つ（HN1）です。ヘッダー保護はパケット 保護AEADの後に適用され、AEAD出力から一連のバイト（sample）をサンプリングし、 次のように擬似乱数関数（PRF）を使用してヘッダーフィールドを暗号化します。¶

protected_field = field XOR PRF(hp_key, sample)

この文書のヘッダー保護の各方式では、一般的なPRFの代わりに 擬似乱数置換（PRP）を使用します。ただし、すべてのPRPはPRFでもあるため[IMC]、 これらの方式はHN1構成から逸脱しません。¶

hp_keyはパケット保護鍵とは異なるため、 ヘッダー 保護は[NAN]で定義されるAE2セキュリティを実現し、 したがって保護されたパケットヘッダーであるfieldのプライバシーを保証します。この構成に基づく将来のヘッダー保護 方式は、同等の セキュリティ保証を確保するためにPRFを使用MUST。¶

同じ鍵と暗号文サンプルを複数回使用すると、 ヘッダー保護が損なわれる危険があります。同じ鍵と 暗号文サンプルで2つの異なるヘッダーを保護すると、保護されたフィールドの排他的ORが明らかになります。 AEADがPRFとして機能すると仮定し、Lビットをサンプリングする場合、2つの暗号文 サンプルが同一になる確率は2^-L/2に近づきます。これは誕生日限界です。 この文書で説明するアルゴリズムでは、その確率は 2⁶⁴分の1です。¶

攻撃者がパケットヘッダーを変更するのを防ぐため、ヘッダーは パケット保護によって間接的に 認証されます。パケットヘッダー全体が 認証対象の追加データの一部です。偽造または変更された保護フィールドは、 パケット保護を解除して初めて検出できます。¶

9.5. ヘッダー保護のタイミング サイドチャネル

攻撃者はパケット番号またはKey Phaseの値を推測し、 タイミングサイドチャネルを介してエンドポイントに推測を確認させる可能性があります。同様に、 パケット番号長を推測して試し、その結果を露出させることもできます。パケットの受信者が、 パケット保護を解除しようとせずに重複したパケット番号を持つパケットを 破棄する場合、タイミングサイドチャネルを介して、 そのパケット番号が受信済みパケットと一致することが明らかになる可能性があります。認証で サイドチャネルが生じないようにするには、ヘッダー保護の解除、パケット番号の 復元、およびパケット保護の解除という処理全体を、タイミング その他のサイドチャネルなしに一体として適用MUST。¶

パケット送信では、パケットペイロードおよび パケット番号の構築と保護は、パケット 番号またはそのエンコードサイズを明らかにするサイドチャネルを生じさせてはMUST。¶

鍵更新中、新しい鍵の生成に要する時間によって、 鍵更新が発生したことがタイミングサイドチャネルを通じて明らかになる可能性があります。また、 攻撃者がパケットを注入した場合、このサイドチャネルによって注入されたパケットのKey Phaseの値が明らかになる可能性があります。鍵更新を受信した後、エンドポイントは、 セクション6.3で説明されているように、 次の受信パケット保護鍵セットを生成して保存するSHOULD。 鍵更新を受信する前に新しい鍵を生成することで、 パケット受信時にKey Phaseの値を漏らすタイミング信号が生じなくなります。¶

これは、パケット処理中にこの鍵生成を行わないことに依存しており、 エンドポイントが受信用に3セットのパケット保護鍵を保持する必要が生じる場合があります。 すなわち、以前の鍵フェーズ、現在の鍵フェーズ、および 次の鍵フェーズ用です。エンドポイントは代わりに、古い鍵を破棄するまで 次の受信パケット保護鍵の生成を遅らせることを選択でき、その場合は任意の時点で 受信鍵を2セットだけ保持すれば済みます。¶

9.6. 鍵の多様性

TLSを使用する際には、TLSの中心的な鍵スケジュールが使用されます。 TLSハンドシェイクメッセージがシークレットの計算に組み込まれる結果として、 QUICトランスポートパラメーター拡張を含めることで、ハンドシェイク および1-RTT鍵が、TCP上でTLSを実行するサーバーによって生成される可能性がある鍵と 同じにならないことが保証されます。プロトコル間の鍵 同期の可能性を避けるため、鍵の分離を改善する追加の対策が提供されています。¶

QUICパケット保護鍵とIVは、 TLSの対応する鍵とは異なるラベルを使用して導出されます。¶

この分離を維持するため、新しいQUICバージョンは、 パケット保護鍵とIV、およびヘッダー保護 鍵の鍵導出に新しいラベルを定義するSHOULD。このQUICバージョンでは文字列"quic"を使用します。他のバージョンでは、 この文字列の代わりにバージョン固有のラベルを使用できます。¶

Initialシークレットは、ネゴシエートされたQUICバージョン固有の鍵を使用します。 新しいQUICバージョンは、Initial シークレットの計算に使用する新しいソルト値を定義するSHOULD。¶

9.7. ランダム性

QUICは、接続IDなどのプロトコル値に直接使用する場合と、 TLSを介して間接的に使用する場合の両方で、エンドポイントが安全な乱数を生成できることに依存します。 安全な乱数生成に関するガイダンスについては[RFC4086]を参照してください。¶

A.1. 鍵

HKDF-Expand-Label関数の実行中に生成されるラベル （すなわちHkdfLabel.label）と、その出力を生成するためにHKDF-Expand 関数に与えられる値の一部は次のとおりです。¶

client in:

00200f746c73313320636c69656e7420696e00¶

server in:

00200f746c7331332073657276657220696e00¶

quic key:

00100e746c7331332071756963206b657900¶

quic iv:

000c0d746c733133207175696320697600¶

quic hp:

00100d746c733133207175696320687000¶

Initialシークレットは共通です。¶

initial_secret = HKDF-Extract(initial_salt, cid)
    = 7db5df06e7a69e432496adedb0085192
      3595221596ae2ae9fb8115c1e9ed0a44

クライアントパケットを保護するためのシークレットは次のとおりです。¶

client_initial_secret
    = HKDF-Expand-Label(initial_secret, "client in", "", 32)
    = c00cf151ca5be075ed0ebfb5c80323c4
      2d6b7db67881289af4008f1f6c357aea

key = HKDF-Expand-Label(client_initial_secret, "quic key", "", 16)
    = 1f369613dd76d5467730efcbe3b1a22d

iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", "", 12)
    = fa044b2f42a3fd3b46fb255c

hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", "", 16)
    = 9f50449e04a0e810283a1e9933adedd2

サーバーパケットを保護するためのシークレットは次のとおりです。¶

server_initial_secret
    = HKDF-Expand-Label(initial_secret, "server in", "", 32)
    = 3c199828fd139efd216c155ad844cc81
      fb82fa8d7446fa7d78be803acdda951b

key = HKDF-Expand-Label(server_initial_secret, "quic key", "", 16)
    = cf3a5331653c364c88f0f379b6067e37

iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", "", 12)
    = 0ac1493ca1905853b0bba03e

hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", "", 16)
    = c206b8d9b9f0f37644430b490eeaa314

A.2. クライアントInitial

クライアントはInitialパケットを送信します。このパケットの保護されていないペイロードには、 次のCRYPTOフレームと、ペイロードを 1162バイトにするために十分なPADDINGフレームが含まれます。¶

060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff

保護されていないヘッダーは1182バイトの長さを示します。4バイトのパケット 番号、1162バイトのフレーム、および16バイトの認証タグです。ヘッダーには 接続IDとパケット番号2が含まれます。¶

c300000001088394c8f03e5157080000449e00000002

ペイロードを保護すると、ヘッダー保護用にサンプリングされる出力が生成されます。 ヘッダーでは4バイトのパケット番号エンコードを使用しているため、保護されたペイロードの最初の16バイトが サンプリングされ、次のようにヘッダーへ適用されます。¶

sample = d1b1c98dd7689fb8ec11d242b123dc9b

mask = AES-ECB(hp, sample)[0..4]
     = 437b9aec36

header[0] ^= mask[0] & 0x0f
     = c0
header[18..21] ^= mask[1..4]
     = 7b9aec34
header = c000000001088394c8f03e5157080000449e7b9aec34

結果として得られる保護されたパケットは次のとおりです。¶

c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11
d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399
1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c
8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212
30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5
457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208
4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec
4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3
485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db
059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c
7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8
9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556
be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74
68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a
c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00
f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632
291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964
25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd
14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff
ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198
e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd
c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73
203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f
cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e
fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade
a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047
90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2
162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4
40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0
6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e
8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0
be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400
54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab
760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9
f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4
056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064
7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241
e221af44860018ab0856972e194cd934

A.3. サーバーInitial

サーバーは応答として、ACKフレームと CRYPTOフレームを含み、PADDINGフレームを含まない次のペイロードを送信します。¶

02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
020304

サーバーからのヘッダーには、新しい接続IDと、パケット番号1に対する2バイトのパケット 番号エンコードが含まれます。¶

c1000000010008f067a5502a4262b50040750001

その結果、保護後、ヘッダー保護サンプルは 3番目の保護されたバイトから取得されます。¶

sample = 2cd0991cd25b0aac406a5816b6394100
mask   = 2ec0d8356a
header = cf000000010008f067a5502a4262b5004075c0d9

最終的な保護されたパケットは次のようになります。¶

cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a
5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3
dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84
022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4
2158407dd074ee

A.4. Retry

これは、付録A.2のInitialパケットへの応答として 送信される可能性があるRetryパケットを示します。完全性チェックには、クライアントが選択した 接続ID値0x8394c8f03e515708が含まれますが、その値は 最終的なRetryパケットには含まれません。¶

ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f
0f2496ba

A.5. ChaCha20-Poly1305 ショートヘッダーパケット

この例では、ショートヘッダーを持つパケットを保護するために 必要な手順の一部を示します。この例ではAEAD_CHACHA20_POLY1305を使用します。¶

この例では、TLSはアプリケーション書き込みシークレットを生成し、サーバーはそこから HKDF-Expand-Labelを使用して、鍵、IV、ヘッダー 保護鍵、および鍵更新後に使用されるシークレットという4つの値を生成します（この 最後の値は、この例ではこれ以上使用しません）。¶

secret
    = 9ac312a7f877468ebe69422748ad00a1
      5443f18203a07d6060f688f30f21632b

key = HKDF-Expand-Label(secret, "quic key", "", 32)
    = c6d98ff3441c3fe1b2182094f69caa2e
      d4b716b65488960a7a984979fb23e1c8

iv  = HKDF-Expand-Label(secret, "quic iv", "", 12)
    = e0459b3474bdd0e44a41c144

hp  = HKDF-Expand-Label(secret, "quic hp", "", 32)
    = 25a282b9e82f06f21f488917a4fc8f1b
      73573685608597d0efcb076b0ab7a7a4

ku  = HKDF-Expand-Label(secret, "quic ku", "", 32)
    = 1223504755036d556342ee9361d25342
      1a826c9ecdf3c7148684b36b714881f9

次に、空のDestination Connection IDを持つ 最小パケットを保護する手順を示します。このパケットには1つのPINGフレーム （すなわち、0x01だけのペイロード）が含まれ、パケット番号は654360564です。この 例では、長さ3のパケット番号（すなわち49140がエンコードされる）を使用することで、 パケットのペイロードをパディングする必要がなくなります。パケット番号を より少ないバイト数でエンコードする場合はPADDINGフレームが必要になります。¶

pn                 = 654360564 (decimal)
nonce              = e0459b3474bdd0e46d417eb0
unprotected header = 4200bff4
payload plaintext  = 01
payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb

結果として得られる暗号文は可能な最小サイズです。ヘッダー保護用の サンプルを生成するために1バイトをスキップします。¶

sample = 5e5cd55c41f69080575d7999c25a5bfb
mask   = aefefe7d03
header = 4cfe4189

保護されたパケットは、可能な最小パケットサイズである21バイトです。¶

packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb

B.1. AEAD_AES_128_GCMおよびAEAD_AES_256_GCMの使用制限の分析

[GCM-MU]は、TLS 1.3およびQUICで 使用されるAEAD_AES_128_GCMおよびAEAD_AES_256_GCMについて具体的な境界を 規定しています。このセクションでは、いくつかの 単純化した仮定を用いてこの分析を記載します。¶

• 攻撃者が偽造試行に使用する暗号文ブロック数は、 v * l、すなわち偽造試行回数に 各パケットのサイズ（ブロック単位）を乗じた値で上限付けされます。¶
• 攻撃者が行うオフライン作業の量は、 分析内の他の要因を支配しません。¶

[GCM-MU]の境界は、 [AEBounds]で使用されるものより 厳密かつ完全であり、[TLS13]で説明されているものよりも 大きな制限を許容します。¶

2 * (q * l)^2 / 2^n

q <= 2^35 / l

(1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n))
        + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)

v <= 2^64 / l

v <= 2^192 / l

B.2. AEAD_AES_128_CCMの使用制限の分析

TLS [TLS13]および[AEBounds]は、AEAD_AES_128_CCMの使用 制限を規定していません。ただし、QUICとともに使用される任意のAEADには、 機密性と完全性の両方が維持されることを保証する使用制限が必要です。この セクションでは、その分析を記載します。¶

[CCM-ANALYSIS]を この分析の基礎として使用します。その分析結果を用いて、 [TLS13]で選択された値に基づく使用制限を導出します。¶

機密性について、[CCM-ANALYSIS]の定理2は、攻撃者が 理想的な擬似乱数置換（PRP）に対して得る識別上の優位性が、 次の値を超えないことを示しています。¶

(2l * q)^2 / 2^n

[CCM-ANALYSIS]の定理1における完全性制限では、同じ数のメッセージについて 攻撃者に厳密により大きな優位性を与えます。機密性の優位性と 完全性の優位性の目標が同じであるため、 定理1だけを考慮すれば十分です。¶

定理1は、攻撃者が 理想的なPRPに対して得る優位性が次の値を超えないことを示しています。¶

v / 2^t + (2l * (v + q))^2 / 2^n

tとnはいずれも128であるため、第1項は 第2項と比べて無視できるほど小さく、結果に大きな影響を与えることなくその項を除去できます。¶

これにより、暗号化と復号の両方の試行を、 機密性のみについての定理から得られるものと同じ制限で組み合わせる関係が得られます。 目標とする優位性を2^-57とすると、次のようになります。¶

v + q <= 2^34.5 / l

q = vと設定することで、機密性と完全性の両方の 制限値を生成できます。したがって、パケットを2¹¹バイトに制限するエンドポイントでは、 機密性と完全性の両方の制限が2^26.5パケットとなります。パケットサイズを 制限しないエンドポイントでは、制限は2^21.5です。¶