Summary

  • 只有数据包被下一代密钥与 IV 成功处理，变化后的 Key Phase 位才构成已确认的密钥更新。
  • 这能证明对端在该连接上发起了更新，却不能证明更新原因，也不能证明旧密钥已被销毁。
  • 归因必须同时保留数据包、密钥代次、确认、发布与策略审计记录。

一次软件发布期间，监控面板出现 Key Phase 翻转，事故群随即把它称为安全轮换。时间上的重合值得调查，但这个比特本身没有携带原因。

RFC 9001 第 6 节给 Key Phase 的任务很窄：标明保护某个 1-RTT 数据包的是哪一代密钥。它从 0 开始，每次更新时翻转。QUIC 使用自己的换钥机制，而不是 TLS KeyUpdate 消息。这个信号说明哪套密钥应当有效，并不说明采用它们的运营决策。

证据边界写在第 6.2 节。接收方看到相反阶段后，会尝试下一代密钥和 IV。只有处理成功，才能确认对端发起了更新。随后，接收方必须先更新发送密钥，才可确认触发更新的数据包；以新密钥保护的确认包标志着更新完成。因此，只能看到阶段位、却看不到解密结果的流量记录，最多表明“疑似更新”。

顺序同样重要。第 6.1 节禁止在握手确认前更新，也禁止在当前阶段的数据包获确认前再次更新。头部保护密钥不会随之变化。旧的数据包保护密钥至少要保留到新密钥成功解开一个数据包，并宜继续短暂保留，以接收网络重排造成的迟到包。

第 6.3 节与第 6.5 节说明了为何端点会同时保存当前、下一代，有时还包括上一代接收密钥，并要求避免时序侧信道。伪造的阶段位可能触发计算；解密失败既不能证明合法更新，也不能单独证明攻击。

事故回执应联合端点角色、连接指纹、包号、阶段位、解密结果、读写密钥代次、握手确认时间、触发包、新密钥确认包、保留窗口、软件版本、发布批次和密钥策略审计事件。协议能证明密码状态连续推进，外围记录才解释意图与原因。