本文是关于QUIC版本2的网络规范文档译文，尚未完成翻译，欢迎指正。

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

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

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

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

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

版权所有（c）2023 IETF信托及确认为文档作者的个人。保留所有权利。

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

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必须具备的属性。

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

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

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

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

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

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

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

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

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

在《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章对新版本的要求。

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

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

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

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。因此，服务端可以通过使用兼容版本协商在这两个版本之间切换连接。同时支持这两个版本的终端应该支持兼容版本协商，从而避免一次往返。

版本1和版本2之间的兼容版本协商在两个方向都需要满足相同的要求。本章使用来自《QUIC VN》的“原始版本”和“协商版本”。

如果服务端发送Retry包，其必须使用原始版本。客户端忽略使用其他版本的Retry包。客户端必须不在后续包含Retry令牌的Initial包中使用不同的版本。服务端可以在其Retry令牌中编码QUIC版本，以验证客户端没有切换版本，并在发生切换时丢弃数据包，从而强制客户端遵守此规则。

QUIC版本2使用与QUIC版本1相同的传输参数来认证Retry。在Retry之后切换到协商版本时，服务端必须包含相关的传输参数，以验证服务端发送了该Retry以及交换中使用的连接ID，如《QUIC》第7.3节所述。

服务端在处理完客户端的传输参数之前不能发送CRYPTO帧。服务端必须使用协商版本发送所有CRYPTO帧。

客户端通过观察首个与原始版本不同的长包头Version字段来获知协商版本。如果客户端从服务端收到原始版本的CRYPTO帧，则表明协商版本等于原始版本。

在服务端能够处理客户端的传输参数之前，它可能需要响应客户端的Initial包。对于这些数据包，服务端使用原始版本。

一旦客户端获知了协商版本，它应该使用该版本发送后续的Initial包。服务端必须不丢弃其原始版本的Initial接收密钥，直到它成功处理了一个协商版本的Handshake包。

双方终端必须使用协商版本发送Handshake和1-RTT包。终端必须丢弃使用其他任何版本的数据包。终端无需生成能够解密或认证此类数据包的密钥材料。

客户端必须不使用协商版本发送0-RTT包，即使在处理了来自服务端的该版本数据包之后也是如此。服务端可以接受0-RTT，然后处理来自原始版本的0-RTT包。

TLS会话票据和NEW_TOKEN令牌与提供它们的连接的QUIC版本绑定。客户端必须不使用来自QUIC版本1连接的会话票据或令牌来发起QUIC版本2连接，反之亦然。当连接包含兼容版本协商时，任何已发放的服务端令牌被视为源于协商版本而非原始版本。

服务端必须验证任何会话票据或令牌的原始版本，不得接受来自不同版本的票据或令牌。被拒绝的票据将导致回退到完整的TLS握手，且不使用0-RTT。被拒绝的令牌将导致客户端地址保持未验证状态，从而限制服务端可以发送的数据量。

在兼容版本协商之后，任何产生的会话票据都映射到协商版本而非原始版本。

QUIC版本2提供了针对某些形式固化的防护。假设所有长包头都将编码为版本1，或假设版本1的Initial密钥派生公式将保持版本不变的设备，将无法正确处理版本2的数据包。

然而，许多中间设备（如防火墙）关注的是连接中的首个数据包，而该数据包出于上述考量通常仍保持版本1的格式。

有意对抗中间设备固化的客户端，如果合理地确信服务端支持版本2，并且愿意在判断错误时承受一次往返的代价，则可以使用版本2发起连接。特别是，为版本2签发会话票据的服务端表明其有意在票据有效期内维持对版本2的支持，即使该支持无法得到保证。

QUIC版本2在应用程序可用的能力方面与QUIC版本1相比没有任何变化。因此，所有被指定为可运行于QUIC版本1之上的应用层协议协商（ALPN）《RFC7301》代码点也可运行于此版本QUIC之上。特别是，“h3”《HTTP/3》和“doq”《RFC9250》这两个ALPN均可运行于QUIC版本2之上。

除非另有说明，所有被定义为适用于版本1的QUIC扩展同样适用于版本2。

QUIC版本2未对QUIC版本1的安全性或隐私属性引入任何变化。

强制性的版本协商机制可防范降级攻击，但由于两个版本的属性完全相同，降级不会带来安全影响。

对QUIC版本2的支持可能帮助观察者对客户端和服务端设备进行指纹识别。

IANA已向维护于 https://www.iana.org/assignments/quic 的“QUIC Versions”注册表添加了以下条目。

值：0x6b3343cf状态：永久规范：RFC 9369变更控制方：IETF联系人：QUIC WG

值：0x709a50c4状态：临时规范：RFC 9369变更控制方：IETF联系人：QUIC WG备注：QUIC v2草案代码点

本附录展示了数据包保护的示例，以便实现者能够逐步验证其实现。文中定义了来自客户端和服务器的Initial数据包样本，以及一个Retry数据包样本。这些数据包使用一个由客户端选择的8字节目标连接ID，其值为0x8394c8f03e515708。文中还包含了一些中间值。所有值均以十六进制表示。

在HKDF-Expand-Label函数执行过程中生成的标签（即HkdfLabel.label），以及为生成输出而提供给HKDF-Expand函数的值的一部分如下：

client in: 00200f746c73313320636c69656e7420696e00

server in: 00200f746c7331332073657276657220696e00

quicv2 key: 001010746c73313320717569637632206b657900

quicv2 iv: 000c0f746c7331332071756963763220697600

quicv2 hp: 00100f746c7331332071756963763220687000

初始密钥通常是：

initial_secret = HKDF-Extract(initial_salt, cid)
    = 2062e8b3cd8d52092614b8071d0aa1fb
      7c2e3ac193f78b280e72d8f5751f6aba

用于保护客户端数据包的密钥是：

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

用于保护服务端数据包的密钥是：

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

客户端发送一个Initial数据包。该数据包的未加密载荷包含以下CRYPTO帧，以及足够的PADDING帧以使载荷达到1162字节：

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

未加密包头指示的长度为1182字节：4字节的数据包编号、1162字节的帧数据以及16字节的认证标签。包头包含连接ID和数据包编号2：

d36b3343cf088394c8f03e5157080000449e00000002

对载荷进行保护会产生一个输出，该输出将被采样用于包头保护。由于包头使用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

最终得到的受保护数据包如下：

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

服务器响应时发送以下载荷，包含一个 ACK 帧、一个 CRYPTO 帧，且不包含 PADDING 帧：

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

服务器的包头包含一个新的连接 ID，以及用于数据包编号 1 的 2 字节数据包编号编码：

d16b3343cf0008f067a5502a4262b50040750001

因此，在保护之后，包头保护样本从第三个受保护字节开始提取：

sample = 6f05d8a4398c47089698baeea26b91eb
mask   = 4dd92e91ea
header = dc6b3343cf0008f067a5502a4262b5004075d92f

最终的受保护数据包如下：

dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2
c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8
4bed8521e2e140

本附录展示了一个可能响应附录A.2中的Initial数据包而发送的Retry数据包。完整性检查包含客户端选择的连接ID值0x8394c8f03e515708，但该值不包含在最终的Retry数据包中：

cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
65dcc7b6

本示例展示了使用短包头保护数据包所需的部分步骤。它使用AEAD_CHACHA20_POLY1305算法。

在本示例中，TLS生成一个应用层写入密钥，服务器使用HKDF-Expand-Label和SHA2-56算法从该密钥派生四个值：一个密钥、一个初始化向量（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

以下展示了使用空目标连接ID保护最小数据包所涉及的步骤。该数据包包含一个PING帧（即仅为0x01的载荷），其数据包编号为654360564。在本示例中，使用长度为3的数据包编号（即编码为49140）可避免对数据包载荷进行填充；如果数据包编号使用更少的字节编码，则需要PADDING帧。

pn                 = 654360564 (decimal)
nonce              = a6b5bc6ab7dafce328ff4a29
unprotected header = 4200bff4
payload plaintext  = 01
payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba

生成的密文为可能的最小大小。跳过一个字节以生成包头保护样本。

sample = e7b6b932bc27d786f4bc2bb20f2162ba
mask   = 97580e32bf
header = 5558b1c6

受保护的数据包是可能的最小数据包大小，为21字节。

packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba

感谢Nick Banks、Mike Bishop、Martin Duke、Ryan Hamilton、Roberto Peon、Anthony Rossi及Martin Thomson的投入和贡献！

David Schinazi

美国加州山景城94043圆形剧场公园路1600号谷歌公司

Email: dschinazi.ietf@gmail.com

Eric Rescorla

Mozilla

Email: ekr@rtfm.com

译

• 方秋航
  • Email: fangqiuhang@163.com