QUIC-TLS
HTTP/3のベースになるQUICとTLSの組み合わせ 概要
このドキュメントでは、トランスポート層セキュリティ（TLS）を使用してQUICを保護する方法について説明します。
1. はじめに
TLS 1.3 は、以前のバージョンと比較して、接続確立のレイテンシを大幅に改善します。パケットロスがない場合、ほとんどの新規接続は1回のラウンドトリップで確立およびセキュリティ保護されます。同じクライアントとサーバー間の後続の接続では、クライアントは多くの場合、アプリケーションデータを即座に送信できます。つまり、ラウンドトリップゼロのセットアップで済みます。このドキュメントでは、TLS が QUIC のセキュリティコンポーネントとしてどのように機能するかについて説明します。
2. 表記規則
本文書におけるキーワード「MUST（しなければならない）」、「MUST NOT（してはならない）」、「REQUIRED（必須）」、「SHALL（する）」、「SHALL NOT（するべきではない）」、「SHOULD（すべきである）」、「SHOULD NOT（すべきではない）」、「RECOMMENDED（推奨される）」、「NOT RECOMMENDED（推奨されない）」、「MAY（してもよい）」、「OPTIONAL（選択できる）」は、ここで示すようにすべて大文字で表記されている場合に限り、BCP 14 RFC2119 RFC8174 の規定に従って解釈されます。 本文書では、QUIC-TRANSPORT で確立された用語を使用します。簡潔にするため、TLS という略語は TLS 1.3 を指しますが、より新しいバージョンを使用することもできます。詳細はセクション 4.2 を参照してください。 2.1. TLS の概要
TLS は、2 つのエンドポイントに、信頼できない媒体（インターネットなど）を介した通信手段を確立する手段を提供します。TLS は、ピアの認証を可能にし、エンドポイント間で交換されるメッセージの機密性と整合性を保護します。
TLS は内部的に階層化プロトコルであり、その構造は図 1 に示されています。
code:TLS レイヤー
+---------------+---------+-----------------+-------+
コンテンツ | | | アプリケーション | |
レイヤー | ハンドシェイク | アラート | データ | ... |
| | | | |
+---------------+---------+-----------------+-------+
レコード | |
レイヤー | レコード |
| |
+---------------------------------------------------+
図 1: TLS レイヤー
コンテンツ層の各メッセージ（ハンドシェイク、アラート、アプリケーションデータなど）は、レコード層によって一連の型付き TLS レコードとして伝送されます。レコードは個別に暗号的に保護され、信頼性の高いトランスポート（通常は TCP）を介して送信されます。これにより、順序付けと配信の保証が提供されます。
TLS 認証による鍵交換は、クライアントとサーバーの 2 つのエンドポイント間で行われます。クライアントが鍵交換を開始し、サーバーが応答します。鍵交換が正常に完了すると、クライアントとサーバーの両方が秘密鍵で合意します。TLS は、有限体または楕円曲線 ((EC)DHE) 鍵交換における事前共有鍵 (PSK) と Diffie-Hellman の両方をサポートしています。PSK は Early Data (0-RTT) の基盤であり、後者は (EC)DHE 鍵が破棄された際に Forward Secrecy (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 に示します。
code:TLS Handshake with 0-RTT
クライアント サーバー
ClientHello
(0-RTT アプリケーションデータ) -------->
ServerHello
{EncryptedExtensions}
{Finished}
{Finished} -------->
() は、早期データ (0-RTT) 鍵で保護されたメッセージを示します。
{} は、ハンドシェイク鍵を使用して保護されたメッセージを示します。
[] は、アプリケーションデータ (1-RTT) 鍵を使用して保護されたメッセージを示します。
図 2: 0-RTT を使用した TLS ハンドシェイク
図 2 では、QUIC では使用されない EndOfEarlyData メッセージが省略されています。セクション8.3を参照してください。同様に、ChangeCipherSpecメッセージもKeyUpdateメッセージもQUICでは使用されません。ChangeCipherSpecはTLS 1.3では冗長です。セクション8.4を参照してください。QUICには独自の鍵更新メカニズムがあります。セクション6を参照してください。
データは複数の暗号化レベルを使用して保護されます。
初期鍵
初期データ（0-RTT）鍵
ハンドシェイク鍵
アプリケーションデータ（1-RTT）鍵
アプリケーションデータは初期データレベルとアプリケーションデータレベルでのみ使用できます。ハンドシェイクメッセージとアラートメッセージはどのレベルでも使用できます。
0-RTTハンドシェイクは、クライアントとサーバーが以前に通信したことがある場合に使用できます。1-RTTハンドシェイクでは、クライアントはサーバーから送信されたすべてのハンドシェイクメッセージを受信するまで、保護されたアプリケーションデータを送信できません。