Summary

  • IETF 126 的 CURRENT BoF 讨论用 MLS 管理 TLS 1.3 record layer 的密钥，但 CURRENT 尚未成立工作组，会议纪要还明确说问题陈述尚未被充分理解。
  • 在双方 profile 中，处理 commit 的一端发送经过认证的 EpochKeyUpdate 后可以启用新材料；发起者必须收到并验证该回执，才能把待定状态设为当前状态。
  • “更新已发”“本端已安装”“旧秘密已删除”“新 epoch 下业务已成功”是四张不同的回执。

两端都没说谎，却还没有同一个答案

A 发送 ConnectionUpdate。B 验证并应用 commit，回送 EpochKeyUpdate，随后开始使用新材料。B 的本地日志可以如实写下“已切换”。此时 A 仍处于 Awaiting EpochKeyUpdate；在用待定 commit 产生的状态验证回执之前，A 不得把新状态设为当前状态。

这个不对称区间不是故障，而是安全边界。它阻止发送者把自己的动作冒充成对端的接收、验证和安装。真正的风险，是监控系统把整个过程压缩为一个“轮换成功”。

两个核心文本目前都是个人 Internet-Draft 的 01 版，没有 RFC stream。CURRENT 的 Datatracker 页面仍写着 BoF 和“Not chartered yet”。IETF 126 现场还质疑：问题是否足够清楚、双方协议是否匹配多方用例、现有 TLS 扩展是否已能解决部分需求。因此这是一项值得继续澄清的提案，不是已经批准的架构。

PCS 不是发送时刻产生的属性

RFC 9420 的表述很严格：Update proposal 本身不会实现 post-compromise security；其他成员把它纳入 Commit 并处理后，保证才生效。forward secrecy 还依赖旧私钥和已经使用的消息密钥被真正删除。

CURRENT 的草案把这套纪律映射到双方通道。MLS exporter 产生供 TLS record layer 使用的 traffic secret；in-band commit 推进 epoch；认证回执证明对端知道新的状态。但它仍不能单独证明所有旧副本已经消失、攻击者已失去终端访问、身份仍有效，或上层业务继续完成。

“支持 PCS”可以描述设计能力，不能为暴露窗口的关闭时间盖章。运行证据必须回答：哪一端何时处理、何时安装、何时删除、何时首次成功处理新 epoch 的业务记录。

冲突解决也会留下不同历史

双方可能同时发起更新。草案按初始角色消解碰撞：一端忽略竞争 commit，另一端丢弃自己的待定 commit 并处理对端版本。最终可以收敛，但两端走过的路径并不相同。

连接中断后的恢复还可能携带待定 commit。接收者要识别已处理过的相同 commit，避免再次应用；另一些情况下，新收到的 commit 会反向证明此前的待定状态已被包含。至于怎样判断连接已经中断，草案明确留给底层 transport。

如果审计只保留最终 epoch 编号，普通确认、碰撞、重传和恢复就会变成同一条记录，也无法解释旧材料究竟保留了多久。

八张回执

Lu Heng 的 Minimum Initial Specification 适合限定共同层：协议只应规定互操作所需的确定性消息和状态转换。Running-Code Primacy 则把实际验证、安装和删除的端点状态置于功能标签之上。现实层次要求分开保存：更新创建、commit 发出、对端认证、对端应用、确认返回、发起端安装、旧材料删除，以及首条新 epoch 业务记录成功认证。

草案自身也说明了不确定性：完整 security analysis、cross-protocol 分离和部分消息封装仍有 TODO。BoF 能确认问题值得讨论，不能把未完成文本变成共识或部署事实。

来源与限制

这些来源不证明 CURRENT 已成立工作组、IETF 已形成共识、草案已被采用、RFC 已发布、安全分析已完成、互操作或部署已发生、复原已经测量、PQC 已上线、事故已经发生或业务结果已经实现。