[要約] RFC 9369 は、QUIC Version 2 を定義しており、QUIC Version 1 とほぼ同じであり、いくつかの些細な詳細が異なります。その目的は、さまざまな硬化ベクトルとバージョンネゴシエーションフレームワークの機能を確認することです。
Internet Engineering Task Force (IETF) M. Duke
Request for Comments: 9369 Google LLC
Category: Standards Track May 2023
ISSN: 2070-1721
This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.
このドキュメントは、QUICバージョン2を指定します。これは、些細な詳細を除き、QUICバージョン1と同じです。その目的は、さまざまな骨化ベクターと闘い、バージョンのネゴシエーションフレームワークを行使することです。また、QUICの将来のバージョンの最小変更のテンプレートとしても機能します。
Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.
「バージョン2」は、この提案の非公式名であり、標準トラックドキュメントとして公開されるQUICの2番目のバージョンであることを示すことに注意してください。ここで指定されているプロトコルは、骨化リスクを最小限に抑えるために、ワイヤ画像に2以外のバージョン番号を使用します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9369.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9369で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions
3. Differences with QUIC Version 1
3.1. Version Field
3.2. Long Header Packet Types
3.3. Cryptography Changes
3.3.1. Initial Salt
3.3.2. HMAC-based Key Derivation Function (HKDF) Labels
3.3.3. Retry Integrity Tag
4. Version Negotiation Considerations
4.1. Compatible Negotiation Requirements
5. TLS Resumption and NEW_TOKEN Tokens
6. Ossification Considerations
7. Applicability
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Sample Packet Protection
A.1. Keys
A.2. Client Initial
A.3. Server Initial
A.4. Retry
A.5. ChaCha20-Poly1305 Short Header Packet
Acknowledgments
Author's Address
QUIC version 1 [QUIC] has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes that are usually 0x00000001.
QUICバージョン1 [QUIC]には、すべての長いヘッダーの2番目の5番目のバイトを占めるバージョン番号を含む多数の拡張ポイントがあります（[quic-invariants]を参照）。実験バージョンがまれであり、QUICバージョン1がQUICトラフィックの大部分を構成する場合、通常0x00000001のバージョンバイトでミドルボックスが骨化する可能性があります。
In QUIC version 1, Initial packets are encrypted with the version-specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.
QUICバージョン1では、[QUIC-TLS]のセクション5.2で説明されているように、初期パケットはバージョン固有の塩で暗号化されています。この方法で初期パケットを保護することで、観察者はコンテンツを検査できます。これには、TLSクライアントのHelloまたはServer Helloメッセージが含まれます。繰り返しますが、バージョン1のキー派生とパケット形式でミドルボックスが骨化する可能性があります。
Finally, [QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically.
最後に、[QUIC-VN]は、選択するQUICバージョンをネゴシエートするためにエンドポイントが使用できる2つのメカニズムを説明します。「互換性のない」バージョンネゴシエーション方法は、接続の開始時に追加の往復を犠牲にして、QUICバージョンから他のバージョンの完全なバージョンへの切り替えをサポートできます。「互換性のある」バージョンのネゴシエーションは、往復ペナルティを排除しますが、2つのバージョンがセマンティブで異なる可能性についての制限を課します。
QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version.
QUICバージョン2は、骨化の懸念を軽減し、バージョン交渉メカニズムを行使することを目的としています。この変更は、新しいQUICバージョンを指定するために必要な最小の変更セットの例を提供します。ただし、ワイヤー上のバージョン番号の選択は「2」ではなくランダムに選択されており、各長いヘッダーパケットタイプを識別する2つのビットはバージョン1とは異なることに注意してください。これらのプロパティは両方とも、骨化と闘うことを目的としており、新しいQUICバージョンには厳密に要求されていません。
Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.
2つのバージョンをサポートするエンドポイントは、ダウングレード攻撃から保護するためにバージョンネゴシエーションを実装する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY]. The remainder of this section lists the differences.
いくつかの違いを除いて、QUICバージョン2エンドポイントは、[QUIC]、[QUIC-TLS]、および[QUIC-Recovery]で説明されているQUICバージョン1仕様を実装する必要があります。このセクションの残りには、違いがリストされています。
The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".
ロングヘッダーのバージョンフィールドは0x6B3343CFです。これは、「Quicv2バージョン番号」のSHA256Sumの最初の4バイトを取得することによって生成されました。
All version 2 Long Header packet types are different. The Type field values are:
すべてのバージョン2ロングヘッダーパケットタイプは異なります。タイプフィールド値は次のとおりです。
* Initial: 0b01
* 初期：0B01
* 0-RTT: 0b10
* 0-RTT：0B10
* Handshake: 0b11
* 握手：0B11
* Retry: 0b00
* 再試行：0b00
The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:
[quic-tls]のセクション5.2の初期キーを導き出すために使用される塩は次のように変更されます。
initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9
This is the first 20 bytes of the sha256sum of "QUICv2 salt".
これは、「Quicv2塩」のSha256Sumの最初の20バイトです。
The labels used in [QUIC-TLS] to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for new versions in Section 9.6 of that document.
[QUIC-TLS]で使用されているラベルは、パケット保護キー（セクション5.1）、ヘッダー保護キー（セクション5.4）、再試行タグキー（セクション5.8）、およびキーアップデート（セクション6.1）を「QUICキー」から変更するために導出します。「QUICV2キー」、「QUIC IV」から「QUICV2 IV」から「QUIC HP」から「QUICV2 HP」から「QUICKU」から「QUICV2 KU」から「QUICV2 KU」から「QUICV2 KU」から「QUICV2 KU」から「QUICV2 KU」から「QUICV2 KU」書類。
The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:
再試行整合性タグ（[QUIC-TLS]のセクション5.8）に使用されるキーとノンセは次のように変更します。
secret =
0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
nonce = 0xd86969bc2d7c6d9990efb04a
The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.
秘密は、「Quicv2 Retry Secret」のSha256Sumです。キーとノンセは、それぞれこの秘密から派生しており、それぞれ「quicv2キー」と「quicv2 iv」というラベルがあります。
QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, as it was the original QUIC version used by HTTP/3; therefore, some clients will only support that version.
QUICバージョン2は、バージョン1を非難することを意図していません。サポートバージョン2をサポートするエンドポイントは、他のエンドポイントとの互換性を最大化するためにバージョン1のサポートを継続する可能性があります。特に、HTTPクライアントは多くの場合、Alt-SVC [RFC7838]を使用してQUICサポートを発見します。このメカニズムは現在QUICバージョンを区別していないため、HTTPサーバーは複数のバージョンをサポートして、互換性の確率とQUICバージョンの交渉またはTCPフォールバックに関連するコストを削減する必要があります。たとえば、Alt-SVCの「H3」のオリジン広告サポートは、HTTP/3が使用している元のQUICバージョンであるため、QUICバージョン1をサポートする必要があります。したがって、一部のクライアントはそのバージョンのみをサポートします。
Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.
QUICバージョン2をサポートするquicエンドポイントは、バージョンのダウングレード攻撃を防ぐために、[quic-vn]で指定されたバージョン_informationTransportパラメーターを送信、処理、および検証する必要があります。
Note that version 2 meets the definition in [QUIC-VN] of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip.
バージョン2は、バージョン1と互換性のあるバージョンの[quic-vn]の定義を満たしており、バージョン1はバージョン2と互換性があることに注意してください。したがって、サーバーは互換性のあるネゴシエーションを使用して、2つのバージョン間の接続を切り替えることができます。両方のバージョンをサポートするエンドポイントは、往復を避けるために互換性のあるバージョンのネゴシエーションをサポートする必要があります。
Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN].
バージョン1と2の間の互換性のあるバージョンのネゴシエーションは、どちらの方向でも同じ要件に従います。このセクションでは、[quic-vn]の「オリジナルバージョン」と「ネゴシエートバージョン」という用語を使用します。
If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance.
サーバーが再試行パケットを送信する場合、元のバージョンを使用する必要があります。クライアントは、他のバージョンを使用して再試行パケットを無視します。クライアントは、再試行トークンを含む後続の初期パケットで別のバージョンを使用してはなりません。サーバーは、retryトークンでQUICバージョンをエンコードして、クライアントがバージョンを切り替えていないことを検証し、スイッチした場合はパケットをドロップしてクライアントコンプライアンスを実施する場合があります。
QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC].
QUICバージョン2では、同じトランスポートパラメーターを使用して、QUICバージョン1として再試行を認証します。再試行後にネゴシエートバージョンに切り替えた後、サーバーには、サーバーが再試行を送信したことを検証するために、サーバーに関連するトランスポートパラメーターを含める必要があります。[QUIC]のセクション7.3で説明されているように、交換。
The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version.
サーバーは、クライアントのトランスポートパラメーターを処理するまで、暗号フレームを送信できません。サーバーは、ネゴシエートバージョンを使用してすべての暗号フレームを送信する必要があります。
The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, it indicates that the negotiated version is equal to the original version.
クライアントは、元のバージョンとは異なる最初のロングヘッダーバージョンフィールドを観察することにより、ネゴシエートバージョンを学習します。クライアントが元のバージョンのサーバーから暗号フレームを受信した場合、ネゴシエートされたバージョンが元のバージョンに等しいことを示します。
Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version.
サーバーがクライアントからの輸送パラメーターを処理する前に、クライアントからの初期パケットに応答する必要がある場合があります。これらのパケットでは、サーバーは元のバージョンを使用します。
Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version.
クライアントがネゴシエートバージョンを学習したら、そのバージョンを使用して後続の初期パケットを送信する必要があります。サーバーは、元のバージョンの初期受信キーを破棄してはならないのは、ネゴシエートバージョンでハンドシェイクパケットを正常に処理するまでです。
Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets.
両方のエンドポイントは、ネゴシエートバージョンを使用してハンドシェイクと1-RTTパケットを送信する必要があります。エンドポイントは、他のバージョンを使用してパケットをドロップする必要があります。エンドポイントには、そのようなパケットを復号化または認証できるキーイン材料を生成する必要はありません。
The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.
クライアントは、サーバーからそのバージョンのパケットを処理した後でも、ネゴシエートバージョンを使用して0-RTTパケットを送信してはなりません。サーバーは0-RTTを受け入れ、元のバージョンから0-RTTパケットを処理できます。
TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one.
TLSセッションチケットとnew_tokenトークンは、それらを提供する接続のQUICバージョンに固有のものです。クライアントは、QUICバージョン1接続のセッションチケットまたはトークンを使用して、QUICバージョン2接続を開始してはなりません。その逆も同様です。接続に互換性のあるバージョンのネゴシエーションが含まれる場合、発行されたサーバートークンは、元のバージョンではなく、ネゴシエートされたバージョンから発生すると見なされます。
Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send.
サーバーは、セッションチケットまたはトークンの発信バージョンを検証し、別のバージョンから発行されたものを受け入れない必要があります。拒否されたチケットは、0-RTTなしで完全なTLSの握手に戻ることになります。拒否されたトークンの結果は、クライアントアドレスが未確認のままであるため、サーバーが送信できるデータの量を制限します。
After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.
互換性のあるバージョンのネゴシエーションの後、結果として生じるセッションチケットは、元のバージョンではなく、ネゴシエートされたバージョンにマップされます。
QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets.
QUICバージョン2は、いくつかの形式の骨化に対する保護を提供します。すべての長いヘッダーがバージョン1をエンコードすると仮定するデバイス、またはバージョン1の初期キー派生式はバージョンin variantのままであると、バージョン2パケットを正しく処理しません。
However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above.
ただし、ファイアウォールなどの多くのミドルボックスは、接続内の最初のパケットに焦点を当てています。これは、上記の考慮事項のためにバージョン1形式に残ることがよくあります。
Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are reasonably certain the server supports it and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.
ミドルボックスの骨化との闘いに関心のあるクライアントは、サーバーがそれをサポートしていることを合理的に確信している場合は、バージョン2を使用して接続を開始できます。特に、バージョン2のセッションチケットを発行するサーバーは、サポートを保証できなくても、チケットが有効なままである間、バージョン2サポートを維持する意図を示します。
QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2.
QUICバージョン2は、アプリケーションで利用可能な機能について、QUICバージョン1からの変更を提供しません。したがって、QUICバージョン1で動作するように指定されたすべてのアプリケーション層プロトコルネゴシエーション（ALPN）[RFC7301]コードポイントも、このバージョンのQUICで動作することができます。特に、「H3」[HTTP/3]と「DOQ」[RFC9250]の両方が、QUICバージョン2で動作することができます。
Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.
特に明記しない限り、バージョン1で動作するように定義されるすべてのQUIC拡張機能もバージョン2で動作します。
QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.
QUICバージョン2では、QUICバージョン1のセキュリティまたはプライバシープロパティに変更がありません。
The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical.
必須バージョンのネゴシエーションメカニズムは、ダウングレード攻撃に対して守られていますが、バージョンのプロパティが同一であるため、ダウングレードにはセキュリティの意味がありません。
Support for QUIC version 2 can help an observer to fingerprint both client and server devices.
QUICバージョン2のサポートは、オブザーバーがクライアントデバイスとサーバーデバイスの両方を指紋するのに役立ちます。
IANA has added the following entries to the "QUIC Versions" registry maintained at <https://www.iana.org/assignments/quic>.
IANAは、<https://www.iana.org/assignments/quic>に維持されている「QUICバージョン」レジストリに次のエントリを追加しました。
Value:
価値：
0x6b3343cf
0x6b3343cf
Status:
状態：
permanent
永続パーマネント恒久常任不変永住永久的な一定不変
Specification:
仕様：
RFC 9369
RFC 9369
Change Controller:
Change Controller：
IETF
IETF
Contact:
接触：
QUIC WG
quic wg
Value:
価値：
0x709a50c4
0x709A50C4
Status:
状態：
provisional
仮仮設一時の一時的
Specification:
仕様：
RFC 9369
RFC 9369
Change Controller:
Change Controller：
IETF
IETF
Contact:
接触：
QUIC WG
quic wg
Notes:
ノート：
QUIC v2 draft codepoint
QUIC V2ドラフトコードポイント
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version
Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May
2023, <https://www.rfc-editor.org/info/rfc9368>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.
このセクションでは、実装を段階的に検証できるように、パケット保護の例を示しています。クライアントとサーバーの両方からの初期パケットと再試行パケットのサンプルが定義されています。これらのパケットは、0x8394C8F03E515708の8バイトのクライアントが選択した宛先接続IDを使用します。いくつかの中間値が含まれています。すべての値は16進数で表示されます。
The labels generated during the execution of the HKDF-Expand-Label function (that is, HkdfLabel.label) and part of the value given to the HKDF-Expand function in order to produce its output are:
HKDF-EXPAND-Label関数（つまり、HKDFLABEL.LABEL）の実行中に生成されたラベルと、その出力を生成するためにHKDF-Expand関数に与えられた値の一部は次のとおりです。
client in: 00200f746c73313320636c69656e7420696e00
クライアント：00200F746C73333320636C69656E7420696E00
server in: 00200f746c7331332073657276657220696e00
サーバーIn：00200F746C7333332073657276657220696E00
quicv2 key: 001010746c73313320717569637632206b657900
Quicv2キー：001010746C73313320717569637632206B657900
quicv2 iv: 000c0f746c7331332071756963763220697600
Quicv2 IV：000C0F746C733332071756963763220697600
quicv2 hp: 00100f746c7331332071756963763220687000
Quicv2 HP：00100F746C733332071756963763220687000
The initial secret is common:
最初の秘密は一般的です：
initial_secret = HKDF-Extract(initial_salt, cid)
= 2062e8b3cd8d52092614b8071d0aa1fb
7c2e3ac193f78b280e72d8f5751f6aba
The secrets for protecting client packets are:
クライアントパケットを保護するための秘密は次のとおりです。
client_initial_secret
= HKDF-Expand-Label(initial_secret, "client in", "", 32)
= 14ec9d6eb9fd7af83bf5a668bc17a7e2
83766aade7ecd0891f70f9ff7f4bf47b
key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16)
= 8b1a0bc121284290a29e0971b5cd045d
iv = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12)
= 91f73e2351d8fa91660e909f
hp = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16)
= 45b95e15235d6f45a6b19cbcb0294ba9
The secrets for protecting server packets are:
サーバーパケットを保護するための秘密は次のとおりです。
server_initial_secret
= HKDF-Expand-Label(initial_secret, "server in", "", 32)
= 0263db1782731bf4588e7e4d93b74639
07cb8cd8200b5da55a8bd488eafc37c1
key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16)
= 82db637861d55e1d011f19ea71d5d2a7
iv = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12)
= dd13c276499c0249d3310652
hp = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16)
= edf6d05c83121201b436e16877593c3a
The client sends an Initial packet. The unprotected payload of this packet contains the following CRYPTO frame, plus enough PADDING frames to make a 1162-byte payload:
クライアントは初期パケットを送信します。このパケットの保護されていないペイロードには、次の暗号フレームに加えて、1162バイトのペイロードを作成するのに十分なパディングフレームが含まれています。
060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff
The unprotected header indicates a length of 1182 bytes: the 4-byte packet number, 1162 bytes of frames, and the 16-byte authentication tag. The header includes the connection ID and a packet number of 2:
保護されていないヘッダーは、1182バイトの長さを示します。4バイトパケット番号、1162バイトのフレーム、16バイト認証タグです。ヘッダーには、接続IDと2のパケット番号が含まれています。
d36b3343cf088394c8f03e5157080000449e00000002
Protecting the payload produces an output that is sampled for header protection. Because the header uses a 4-byte packet number encoding, the first 16 bytes of the protected payload is sampled and then applied to the header as follows:
ペイロードを保護すると、ヘッダー保護のためにサンプリングされる出力が生成されます。ヘッダーは4バイトのパケット番号エンコードを使用するため、保護されたペイロードの最初の16バイトがサンプリングされ、次のようにヘッダーに適用されます。
sample = ffe67b6abcdb4298b485dd04de806071
mask = AES-ECB(hp, sample)[0..4]
= 94a0c95e80
header[0] ^= mask[0] & 0x0f
= d7
header[18..21] ^= mask[1..4]
= a0c95e82
header = d76b3343cf088394c8f03e5157080000449ea0c95e82
The resulting protected packet is:
結果の保護されたパケットは次のとおりです。
d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485
dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04
9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d
250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a
12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500
cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68
18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33
12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3
d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd
6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520
bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045
636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f
ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12
16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5
4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4
fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b
8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7
14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9
9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91
abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd
80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db
848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18
d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15
c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc
7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61
f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710
10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b
3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e
06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce
8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1
34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1
e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd
5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3
8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89
d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53
6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19
9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b
a18b2faa745b6fe189cf772a9f84cbfc
The server sends the following payload in response, including an ACK frame, a CRYPTO frame, and no PADDING frames:
サーバーは、ACKフレーム、暗号フレーム、およびパディングフレームなしなど、次のペイロードを応答して送信します。
02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
020304
The header from the server includes a new connection ID and a 2-byte packet number encoding for a packet number of 1:
サーバーのヘッダーには、新しい接続IDとパケット番号の1の2バイトパケット番号エンコードが含まれています。
d16b3343cf0008f067a5502a4262b50040750001
As a result, after protection, the header protection sample is taken, starting from the third protected byte:
その結果、保護後、ヘッダー保護サンプルが採取され、3番目の保護されたバイトから始まります。
sample = 6f05d8a4398c47089698baeea26b91eb
mask = 4dd92e91ea
header = dc6b3343cf0008f067a5502a4262b5004075d92f
The final protected packet is then:
最終的な保護されたパケットは次のとおりです。
dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2
c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8
4bed8521e2e140
This shows a Retry packet that might be sent in response to the Initial packet in Appendix A.2. The integrity check includes the client-chosen connection ID value of 0x8394c8f03e515708, but that value is not included in the final Retry packet:
これは、付録A.2の最初のパケットに応じて送信される可能性のある再試行パケットを示しています。整合性チェックには、0x8394C8F03E515708のクライアント選択接続ID値が含まれていますが、その値は最終的な再試行パケットに含まれていません。
cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
65dcc7b6
This example shows some of the steps required to protect a packet with a short header. It uses AEAD_CHACHA20_POLY1305.
この例は、短いヘッダーでパケットを保護するために必要ないくつかの手順を示しています。AEAD_CHACHA20_POLY1305を使用します。
In this example, TLS produces an application write secret from which a server uses HKDF-Expand-Label to produce four values: a key, an Initialization Vector (IV), a header protection key, and the secret that will be used after keys are updated (this last value is not used further in this example).
この例では、TLSは、サーバーがHKDF-Expand-Labelを使用して4つの値を作成するアプリケーションの書き込み秘密を生成します。キー、初期化ベクトル（IV）、ヘッダー保護キー、およびキーの後に使用される秘密は更新されました（この最後の値は、この例ではこれ以上使用されません）。
secret
= 9ac312a7f877468ebe69422748ad00a1
5443f18203a07d6060f688f30f21632b
key = HKDF-Expand-Label(secret, "quicv2 key", "", 32)
= 3bfcddd72bcf02541d7fa0dd1f5f9eee
a817e09a6963a0e6c7df0f9a1bab90f2
iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12)
= a6b5bc6ab7dafce30ffff5dd
hp = HKDF-Expand-Label(secret, "quicv2 hp", "", 32)
= d659760d2ba434a226fd37b35c69e2da
8211d10c4f12538787d65645d5d1b8e2
ku = HKDF-Expand-Label(secret, "quicv2 ku", "", 32)
= c69374c49e3d2a9466fa689e49d476db
5d0dfbc87d32ceeaa6343fd0ae4c7d88
The following shows the steps involved in protecting a minimal packet with an empty Destination Connection ID. This packet contains a single PING frame (that is, a payload of just 0x01) and has a packet number of 654360564. In this example, using a packet number of length 3 (that is, 49140 is encoded) avoids having to pad the payload of the packet; PADDING frames would be needed if the packet number is encoded on fewer bytes.
以下は、空の宛先接続IDで最小限のパケットを保護することに伴う手順を示しています。このパケットには、単一のpingフレーム（つまり、わずか0x01のペイロード）が含まれており、654360564のパケット番号があります。この例では、長さ3のパケット番号（つまり、49140がエンコードされています）を使用して、ペイロードをパッドにパッドする必要がありません。パケットの;パケット番号がより少ないバイトでエンコードされている場合、パディングフレームが必要になります。
pn = 654360564 (decimal)
nonce = a6b5bc6ab7dafce328ff4a29
unprotected header = 4200bff4
payload plaintext = 01
payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba
The resulting ciphertext is the minimum size possible. One byte is skipped to produce the sample for header protection.
結果の暗号文は、可能な限り最小サイズです。ヘッダー保護用のサンプルを作成するために、1つのバイトがスキップされます。
sample = e7b6b932bc27d786f4bc2bb20f2162ba
mask = 97580e32bf
header = 5558b1c6
The protected packet is the smallest possible packet size of 21 bytes.
保護されたパケットは、21バイトの可能な限り最小のパケットサイズです。
packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba
The author would like to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions.
著者は、クリスチャン・フイテマ、ルーカス・パルドゥ、カイル・ローズ、アンソニー・ロッシ、ザヘド・サルカー、デビッド・シナジ、タツヒロ・ツジカワ、マーティン・トムソンの有益な提案に感謝したいと思います。
Martin Duke
Google LLC
Email: martin.h.duke@gmail.com