RFC9369 QUIC版本2

状态：	建议标准
更多信息：	数据追踪\| 知识产权\| 信息页
组织：	互联网工程工作组（IETF）
RFC编号：	9369
分类：	标准追踪
出版时间：	2023年5月
国际标准期刊编号：	2070-1721
作者：	M. Duke Google LLC

摘要

本文详细说明QUIC版本2，其与QUIC版本1除了部分微小的细节外都一致。其目的是为了对抗一些僵化的模型，并实现版本协商框架。其也作为一个在任何QUIC的未来版本中作出最小变动的模板。

注意“第2版”对于本协议是一个非正式的名称，表明这是QUIC作为标准追踪文档公开发表的第2个版本。此次制定的协议在网络镜像中使用版本号而不是2，是为了最小化僵化风险。

备忘状态

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9369。

版权声明

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

1. 引言

QUIC版本1^《QUIC》具有许多扩展点，包括每个长头部中占据第二到第五个字节的版本号（详见《QUIC版本通用属性》）。如果实验版本很少见，而QUIC流量的绝大部分是QUIC版本1，那么中间盒就有可能固化在版本字节0x00000001上。

在QUIC版本1中，初始化包使用版本指定的盐值进行加密，如《QUIC TLS》第5.2章所述。以该方式保护初始包允许观察者检查其包内容，包括TLS客户端及服务的Hello消息。同样，中间盒也可能存在固化在版本1的密钥派生及数据包格式上的风险。

最后，《QUIC VN》描述了两种终端用以协商选择何种QUIC版本的机制。“不兼容”版本协商方式可以支持从任何QUIC版本全面切换到另一个版本，代价是在建联阶段多加一个往返。“兼容”版本协商消除了往返延迟，但却对两个版本之间的语义差异程度有一定的限制。

QUIC版本2旨在缓解固化问题，并执行版本协商机制。这些改动提供了一个指定新版本QUIC所需要做的最小改动的示例。然而需要注意的是，链路上选择版本号是随机的，而非只选择“2”，且区分长包头包类型的两个字节也与版本1不同；这两个特性都是为了对抗固化问题，并非新版本QUIC必须具备的属性。

任何支持两个版本的终端都需要实现版本协商，以防范降级攻击。

2. 约定

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

3. 与QUIC版本1的区别

除了一些不同，QUIC版本2终端必须实现QUIC版本1在《QUIC》、《QUIC TLS》以及《QUIC恢复》中所描述的规范。本章接下来罗列不同点。

3.1. 与QUIC版本1的区别

长包头中的版本字段值是0x6b3343cf。这是通过取“QUICv2 version number”（“QUICv2版本号”）的sha256散列值的前四个字节来生成的。

3.2. 长包头包类型

所有版本2长包头包类型都不同。类型字段值分别是：

初始包：0b01
0-RTT包：0b10
握手包：0b11
重试包：0b00

3.3. 密码学相关变化

3.3.1 初始盐值

《QUIC TLS》第5.2章用于推导初始密钥的盐值改为：

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

即“QUICv2 salt”的sha256sum值的前20字节。

3.3.2 基于HMAC的密钥派生函数（HKDF）标签

在《QUIC TLS》中用于推导包保护密钥（详见第5.1章）、头部保护密钥（详见第5.4章）、重试完整性标签密钥（详见第5.8章）以及密钥升级（详见第6.1章）的标签，分别从“quic key”改为“quicv2 key”、“quic iv”改为“quicv2 iv”、“quic hp”改为“quicv2 hp”以及“quic ku”改为“quicv2 ku”，从而满足该文档第9.6章对新版本的要求。

3.3.3 重试完整性标签

用于重试完整性标签（Retry Integrity Tag）的密钥和随机数（详见《QUIC TLS》第5.8章）改为：

secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
nonce = 0xd86969bc2d7c6d9990efb04a

其中secret（密码）就是“QUICv2 retry secret”的sha256sum值。密钥和随机数分别通过标签“quicv2 key”及“quicv2 iv”从这个密码派生而来。

4. 约定

QUIC版本2的目的并不是为了取代QUIC版本1。支持QUIC版本2的终端可能继续支持版本1以最大限度兼容其他终端。特别是，HTTP客户端通常使用Alt-Svc^{《RFC7838》}检测QUIC支持情况。由于该机制目前还无法区别不同的QUIC版本，因此HTTP服务端应该支持多个QUIC版本，从而降低不兼容的概率以及由QUIC版本协商或TCP回退带来的开销。例如，一个在Alt-Svc头部中表示支持“h3”的源站应该支持QUIC版本1，因为HTTP/3最初就是基于QUIC版本1的；因此，一些客户端可能只支持该版本的QUIC。

任何支持QUIC版本2的QUIC终端必须发送、执行并验证《QUIC VN》中定义的传输参数version_information，以防范版本降级攻击。

注意，版本2满足《QUIC VN》中有关兼容QUIC版本1的定义，且QUIC版本1同样兼容版本2。因此，服务端可以通过使用兼容版本协商在这两个版本之间切换连接。同时支持这两个版本的终端应该支持兼容版本协商，从而节省一个往返。

4.1. 兼容协商要求

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.

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].

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.

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.