摘要

  • 有效标签说明发送方看到了客户端的 Initial，也说明参与校验的 Retry 字节没有发生意外损坏。
  • 它不认证指定服务器，不证明服务器会接受令牌，也不表示服务器已经验证客户端地址。
  • 事故证据应分别保存标签校验、令牌回传、服务端令牌验证和 TLS 身份认证结果。

一份抓包里出现带有效完整性标签的 QUIC Retry。监控面板随即把它标成“已认证的服务器挑战”，并把客户端地址改成“已验证”。这两个判断都超出了报文本身的证据范围。

RFC 9001 第 5.8 节给出的保证很窄。128 位标签采用 AEAD_AES_128_GCM 计算，明文为空，关联数据则是 Retry 伪报文：先放入原始目的连接 ID（ODCID）的长度和值，再接上去掉标签后的 Retry 报文。QUIC v1 的计算密钥和 nonce 由规范给定。ODCID 来自客户端 Initial，因此有效标签可以证明发送方观察过该 Initial，同时帮助客户端排除意外损坏。

这不是对端身份认证。计算 QUIC v1 标签所需的固定参数写在公开规范中，而且 Retry 本身没有受保护字段。标签不能替代 TLS 证书和 Finished 的验证结果；它也不能识别具体服务器实例、证明该实例对服务名拥有授权，或排除路径上的系统发送了这个 Retry。

RFC 9000 第 17.2.5 节规定了客户端下一步的机械检查：标签无效或令牌长度为零时必须丢弃 Retry；每次连接尝试最多处理一个 Retry。接受后，客户端发送新的 Initial，把 Retry 的源连接 ID 用作目的连接 ID，并把令牌复制进去。所以，观察到 Retry 只是看到了对回程证明的请求，而不是完成后的证明。

服务端的证据边界见 RFC 9000 第 8.1.2 节。如果攻击者无法为自己的地址生成有效令牌，而客户端能够把令牌带回来，服务器便可确认客户端确实收到了它。服务器仍须验证回传令牌，再决定拒绝连接还是允许继续。只截到出站 Retry 的记录，既不能证明令牌已被接受，也不能证明客户端地址已经验证。

运维回执应关联保存：QUIC 版本、原始 Initial 的五元组与时间、ODCID、Retry 的 DCID 和 SCID、精确报文字节、标签结果、令牌指纹、后续 Initial 的五元组与时间、回传令牌指纹、服务端验证结果、验证域或实例、TLS 证书与 Finished 结果，以及最终连接结局。这样才能区分 anycast 密钥漂移、令牌过期、路径变化和错误路由，而不会把有限的密码学检查夸大成身份结论。