RFC9369 QUIC版本2
前言
本文是关于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文件，并且不附带任何该文件所描述的保证。
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. 约定
3. 与QUIC版本1的区别
3.1. 与QUIC版本1的区别
长包头中的版本字段值是0x6b3343cf。这是通过取“QUICv2 version number”（“QUICv2版本号”）的sha256散列值的前四个字节来生成的。
3.2. 长包头包类型
所有版本2长包头包类型都不同。类型字段值分别是：
- 初始包：
0b01 - 0-RTT包：
0b10 - 握手包：
0b11 - 重试包：
0b00
3.3.1 长包头包类型
The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:
initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9
This is the first 20 bytes of the sha256sum of “QUICv2 salt”.
3.3.2 基于HMAC的密钥派生函数（HKDF）标签
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.
3.3.3 重试完整性标签
The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:
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.