跳到主要内容

RFC 9369 - QUIC 版本 2 (QUIC Version 2)

  • 状态: Proposed Standard
  • 发布日期: 2023年5月
  • 文档流: IETF
  • 勘误: 无勘误

摘要 (Abstract)​

本文档规定 QUIC 版本 2, 除少量细节外与 QUIC 版本 1 相同. 其目的是对抗多种僵化 (ossification) 向量, 并演练版本协商框架. 它也作为未来任何 QUIC 版本所需最小变更的模板.

注意: "版本 2" 是该提案的非正式名称, 表示它是作为 Standards Track 文档发布的第二个 QUIC 版本. 为尽量降低僵化风险, 本文档规定的协议在线路报文中使用的版本号并不是 2.

本备忘录状态 (Status of This Memo)​

这是一份 Internet Standards Track 文档.

本文档是互联网工程任务组 (Internet Engineering Task Force, IETF) 的产物. 它代表 IETF 社区的共识. 它已接受公开审阅, 并已获互联网工程指导组 (Internet Engineering Steering Group, IESG) 批准发布. 有关 Internet Standards 的更多信息, 见 RFC 7841 第 2 节.

有关本文档当前状态、任何勘误以及如何提供反馈的信息, 见 https://www.rfc-editor.org/info/rfc9369.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

本文档受 BCP 78 以及 IETF Trust 关于 IETF 文档的法律条款 (https://trustee.ietf.org/license-info) 约束 (以本文档发布之日有效者为准). 请仔细审阅这些文件. 从本文档提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的 Revised BSD License 文本, 并按该许可证所述不提供保证.

目录 (Table of Contents)​

1. 引言 (Introduction)​

QUIC 版本 1 [QUIC] 具有大量扩展点, 包括占据每个长报头第 2 至第 5 字节的版本号 (见 [QUIC-INVARIANTS]). 若实验版本很少, 且 QUIC 版本 1 构成绝大多数 QUIC 流量, 则中间盒可能对通常为 0x00000001 的版本字节发生僵化.

在 QUIC 版本 1 中, Initial 报文使用版本专用 salt 加密, 如 [QUIC-TLS] 第 5.2 节所述. 以此方式保护 Initial 报文仍允许观察者检查其内容, 包括 TLS Client Hello 或 Server Hello 消息. 同样, 中间盒可能对版本 1 的密钥派生方式与报文格式发生僵化.

最后, [QUIC-VN] 描述了端点协商所选 QUIC 版本的两种机制. "不兼容" 版本协商可在不受版本差异限制的情况下从任意 QUIC 版本切换到任意其他版本, 代价是在连接开始时增加一次往返. "兼容" 版本协商消除了这次额外往返, 但会限制两个版本在语义上的差异程度.

QUIC 版本 2 旨在缓解僵化担忧并演练版本协商机制. 这些变更提供了规定新 QUIC 版本所需最小变更集的示例. 但请注意, 线上版本号是随机选择而非 "2", 且标识各 Long Header 报文类型的两个比特与版本 1 不同; 这两项属性旨在对抗僵化, 并非新 QUIC 版本的严格要求.

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

2. 约定 (Conventions)​

关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 的解释见 BCP 14 [RFC2119] [RFC8174], 且仅当它们全部大写出现时适用.

3. 与 QUIC 版本 1 的差异 (Differences with QUIC Version 1)​

除少数差异外, QUIC 版本 2 端点 MUST 实现 [QUIC], [QUIC-TLS] 与 [QUIC-RECOVERY] 中所述的 QUIC 版本 1 规范. 本节其余部分列出差异.

3.1. Version 字段​

长报头的 Version 字段为 0x6b3343cf. 该值通过对 "QUICv2 version number" 取 sha256sum 的前四个字节生成.

3.2. Long Header 报文类型​

所有版本 2 的 Long Header 报文类型均不同. Type 字段值为:

  • Initial: 0b01

  • 0-RTT: 0b10

  • Handshake: 0b11

  • Retry: 0b00

3.3. 密码学变更 (Cryptography Changes)​

3.3.1. Initial Salt​

[QUIC-TLS] 第 5.2 节中用于派生 Initial 密钥的 salt 变更为:

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

这是 "QUICv2 salt" 的 sha256sum 的前 20 字节.

3.3.2. HMAC-based Key Derivation Function (HKDF) Labels​

[QUIC-TLS] 中用于派生报文保护密钥 (第 5.1 节)、报头保护密钥 (第 5.4 节)、Retry Integrity Tag 密钥 (第 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​

Retry Integrity Tag ([QUIC-TLS] 第 5.8 节) 使用的密钥与 nonce 变更为:

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

secret 是 "QUICv2 retry secret" 的 sha256sum. key 与 nonce 分别使用标签 "quicv2 key" 与 "quicv2 iv" 从该 secret 派生.

4. 版本协商考虑 (Version Negotiation Considerations)​

QUIC 版本 2 并非用于废弃版本 1. 支持版本 2 的端点可继续支持版本 1, 以最大限度地兼容其他端点. 尤其是, HTTP 客户端常使用 Alt-Svc [RFC7838] 发现 QUIC 支持. 由于该机制当前不区分 QUIC 版本, HTTP 服务器 SHOULD 支持多个版本, 以降低不兼容概率以及 QUIC 版本协商或回退到 TCP 的成本. 例如, 在 Alt-Svc 中通告支持 h3 的源站应支持 QUIC 版本 1, 因为它是 HTTP/3 最初使用的 QUIC 版本, 而某些客户端只支持该版本.

任何支持 QUIC 版本 2 的 QUIC 端点 MUST 发送、处理并验证 [QUIC-VN] 中规定的 version_information 传输参数, 以防止版本降级攻击.

注意, 版本 2 满足 [QUIC-VN] 中与版本 1 兼容版本的定义, 且版本 1 与版本 2 兼容. 因此, 服务器可使用兼容协商在两个版本之间切换连接. 支持两个版本的端点 SHOULD 支持兼容版本协商以避免一次往返.

4.1. 兼容协商要求 (Compatible Negotiation Requirements)​

版本 1 与 2 之间的兼容版本协商在任一方向遵循相同要求. 本节使用 [QUIC-VN] 中的术语 "original version" 与 "negotiated version".

若服务器发送 Retry 报文, 它 MUST 使用 original version. 客户端忽略使用其他版本的 Retry 报文. 客户端 MUST NOT 在包含 Retry token 的后续 Initial 报文中使用不同版本. 服务器 MAY 在 Retry token 中编码 QUIC 版本, 以验证客户端没有切换版本; 如果发生切换, 服务器可丢弃报文, 从而强制客户端遵循该要求.

QUIC 版本 2 使用与 QUIC 版本 1 相同的传输参数来认证 Retry. 在 Retry 之后切换到 negotiated version 后, 服务器 MUST 包含相关传输参数, 以验证服务器发送了 Retry 以及交换中使用的连接 ID, 如 [QUIC] 第 7.3 节所述.

服务器在处理完客户端传输参数之前不能发送 CRYPTO 帧. 服务器 MUST 使用 negotiated version 发送所有 CRYPTO 帧.

客户端通过观察第一个与 original version 不同的 long header Version 字段来获知 negotiated version. 若客户端从服务器收到 original version 的 CRYPTO 帧, 则表明 negotiated version 等于 original version.

在服务器能够处理来自客户端的传输参数之前, 它可能需要响应来自客户端的 Initial 报文. 对这些报文, 服务器使用 original version.

一旦客户端获知 negotiated version, 它 SHOULD 使用该版本发送后续 Initial 报文. 服务器 MUST NOT 在成功处理 Handshake 报文之前丢弃其 original version 的 Initial 接收密钥.

两个端点都 MUST 使用 negotiated version 发送 Handshake 和 1-RTT 报文. 端点 MUST 丢弃使用任何其他版本的报文. 端点无需生成用于解密或认证这些报文的密钥材料.

即使客户端已处理来自服务器的 negotiated version 报文, 也 MUST NOT 使用 negotiated version 发送 0-RTT 报文. 服务器可接受 0-RTT, 随后处理来自 original version 的 0-RTT 报文.

5. TLS 恢复与 NEW_TOKEN 令牌 (TLS Resumption and NEW_TOKEN Tokens)​

TLS 会话票据和 NEW_TOKEN 令牌仅适用于提供它们的连接所使用的 QUIC 版本. 客户端 MUST NOT 使用 QUIC 版本 1 连接获得的会话票据或令牌来发起 QUIC 版本 2 连接, 反之亦然. 当连接使用兼容版本协商时, 服务器签发的所有令牌都视为来自 negotiated version, 而非 original version.

服务器 MUST 验证所有会话票据或令牌的来源版本, 且不得接受由其他版本签发的票据或令牌. 会话票据被拒绝会导致回退到不使用 0-RTT 的完整 TLS 握手. 令牌被拒绝会使客户端地址保持未验证状态, 从而限制服务器可发送的数据量.

完成兼容版本协商后, 由此产生的所有会话票据均映射到 negotiated version, 而非 original version.

6. 僵化考虑 (Ossification Considerations)​

QUIC 版本 2 可防御某些形式的僵化. 假定所有 Long Header 都编码版本 1, 或假定版本 1 的 Initial 密钥派生公式不会随版本变化的设备, 将无法正确处理版本 2 报文.

但是, 防火墙等许多中间盒主要关注连接中的首个报文; 由于前述考虑, 该报文通常仍采用版本 1 格式.

希望对抗中间盒僵化的客户端, 如果有合理把握服务器支持版本 2, 且愿意在判断错误时承受一次往返延迟, 可以使用版本 2 发起连接. 特别是, 服务器签发版本 2 的会话票据, 表明它有意在票据有效期间继续支持版本 2, 尽管这种支持无法得到保证.

7. 适用性 (Applicability)​

就应用可用能力而言, QUIC 版本 2 与版本 1 没有区别. 因此, 所有规定可在 QUIC 版本 1 上运行的应用层协议协商 (Application-Layer Protocol Negotiation, ALPN) [RFC7301] 代码点也可在 QUIC 版本 2 上运行. 特别是, h3 [HTTP/3] 和 doq [RFC9250] ALPN 均可在 QUIC 版本 2 上运行.

除非另有说明, 所有定义为与版本 1 配合工作的 QUIC 扩展也可与版本 2 配合工作.

8. 安全考虑 (Security Considerations)​

QUIC 版本 2 未改变 QUIC 版本 1 的安全或隐私属性.

强制版本协商机制可防御降级攻击, 但由于两个版本的属性相同, 降级本身不会造成安全影响.

支持 QUIC 版本 2 可能有助于观察者对客户端和服务器设备进行指纹识别.

9. IANA 考虑 (IANA Considerations)​

IANA 已在 https://www.iana.org/assignments/quic 维护的 "QUIC Versions" 注册表中新增以下条目:

  • Value: 0x6b3343cf

  • Status: permanent

  • Specification: RFC 9369

  • Change Controller: IETF

  • Contact: QUIC WG

  • Value: 0x709a50c4

  • Status: provisional

  • Specification: RFC 9369

  • Change Controller: IETF

  • Contact: QUIC WG

  • Notes: QUIC v2 draft codepoint

10. 参考文献 (References)​

10.1. 规范性引用 (Normative References)​

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

10.2. 资料性引用 (Informative References)​

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

附录 A. 报文保护样例 (Sample Packet Protection)​

本附录给出报文保护示例, 以便实现可逐步进行验证. 示例定义了客户端与服务器的 Initial 报文以及一个 Retry 报文. 这些报文使用由客户端选择的 8 字节 Destination Connection ID 0x8394c8f03e515708. 文中给出若干中间值. 所有数值均以十六进制表示.

A.1. 密钥​

执行 HKDF-Expand-Label 函数时生成的标签 (即 HkdfLabel.label), 以及为生成输出而提供给 HKDF-Expand 函数的部分值如下:

client in: 00200f746c73313320636c69656e7420696e00

server in: 00200f746c7331332073657276657220696e00

quicv2 key: 001010746c73313320717569637632206b657900

quicv2 iv: 000c0f746c7331332071756963763220697600

quicv2 hp: 00100f746c7331332071756963763220687000

初始 secret 是共用的:

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

用于保护客户端报文的 secret 如下:

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

用于保护服务器报文的 secret 如下:

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

A.2. 客户端 Initial​

客户端发送一个 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

A.3. 服务器 Initial​

服务器在响应中发送以下载荷, 其中包含一个 ACK 帧和一个 CRYPTO 帧, 不包含 PADDING 帧:

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

服务器报头包含一个新的连接 ID, 并使用 2 字节编码表示值为 1 的报文编号:

d16b3343cf0008f067a5502a4262b50040750001

因此, 完成保护后, 从第 3 个受保护字节开始取得报头保护样本:

sample = 6f05d8a4398c47089698baeea26b91eb mask = 4dd92e91ea header = dc6b3343cf0008f067a5502a4262b5004075d92f

最终的受保护报文为:

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

A.4. Retry​

以下给出一个可能用于响应附录 A.2 中 Initial 报文的 Retry 报文. 完整性校验包含客户端选择的连接 ID 0x8394c8f03e515708, 但最终 Retry 报文中不包含该值:

cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436 65dcc7b6

A.5. ChaCha20-Poly1305 Short Header 报文​

本例展示保护 Short Header 报文所需的部分步骤, 使用 AEAD_CHACHA20_POLY1305.

本例中, TLS 生成一个 application write secret, 服务器据此使用 HKDF-Expand-Label 生成 4 个值: 一个密钥、一个初始化向量 (IV)、一个报头保护密钥, 以及密钥更新后使用的 secret (本例后续不再使用最后这个值).

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

以下给出保护一个 Destination Connection ID 为空的最小报文所涉及的步骤. 该报文只包含一个 PING 帧 (即载荷仅为 0x01), 报文编号为 654360564. 本例使用长度为 3 的报文编号 (即编码 49140), 从而无需填充报文载荷; 如果用更少字节编码报文编号, 则需要 PADDING 帧.

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

所得密文达到可能的最小长度. 生成报头保护样本时跳过 1 个字节.

sample = e7b6b932bc27d786f4bc2bb20f2162ba mask = 97580e32bf header = 5558b1c6

受保护报文为可能的最小报文大小, 共 21 字节.

packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba

致谢​

作者感谢 Christian Huitema、Lucas Pardue、Kyle Rose、Anthony Rossi、Zahed Sarker、David Schinazi、Tatsuhiro Tsujikawa 和 Martin Thomson 提供的有益建议.

作者地址​

Martin Duke Google LLC Email: [email protected]

最后于 更新