メインコンテンツまでスキップ

2. 表記規則 (Notational Conventions)

本文書のキーワード「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 を指すために使用されますが、より新しいバージョンの TLS を使用することもできます。セクション 4.2 を参照してください。

2.1. TLS 概要 (TLS Overview)​

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

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

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

図1: TLS の階層化

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

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

TLS ハンドシェイクが完了すると、クライアントはサーバーの身元を学習し、認証します。サーバーはオプションでクライアントの身元を学習し、認証できます。TLS は、X.509 [RFC5280] 証明書ベースのサーバーおよびクライアント認証をサポートします。PSK 鍵交換が使用される場合（セッション再開など）、PSK の知識がピアの認証に使用されます。

TLS 鍵交換は攻撃者の改ざんに耐性があり、生成される共有秘密は参加するいずれのピアによっても制御できません。

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

  • 完全な 1-RTT ハンドシェイク：クライアントが1往復後にアプリケーションデータを送信でき、サーバーがクライアントの最初のハンドシェイクメッセージを受信した直後に応答します。

  • 0-RTT ハンドシェイク：クライアントが、以前にサーバーについて学習した情報を使用してアプリケーションデータを即座に送信します。このアプリケーションデータは攻撃者によって再生される可能性があるため、0-RTT は、再生された場合に望ましくない結果を引き起こす可能性のあるアクションをトリガーする命令を運ぶのには適していません。

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

クライアント                                             サーバー

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

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

() 早期データ (0-RTT) 鍵で保護されたメッセージを示します
{} ハンドシェイク鍵で保護されたメッセージを示します
[] アプリケーションデータ (1-RTT) 鍵で保護されたメッセージを示します

図2: 0-RTT を含む TLS ハンドシェイク

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

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

  • 初期鍵 (Initial keys)
  • 早期データ (0-RTT) 鍵 (Early data (0-RTT) keys)
  • ハンドシェイク鍵 (Handshake keys)
  • アプリケーションデータ (1-RTT) 鍵 (Application data (1-RTT) keys)

アプリケーションデータは、早期データレベルとアプリケーションデータレベルでのみ表示できます。ハンドシェイクメッセージとアラートメッセージは、どのレベルでも表示できます。

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

に最終更新