摘要

  • 现行文本是 draft-ietf-tls-extended-key-update-13，不是委托时的第 11 版；它仍是工作中的互联网草案，并非 RFC、获批标准或部署事实。
  • 三条扩展更新消息能够把新共享秘密带入现有 TLS/DTLS 会话，但响应成功、派生成功与新密钥记录可解密，分别只是不同层级的回执。
  • 可信的恢复结论必须串联能力协商、消息顺序、新材料生成、旧状态销毁、两个方向的切换、失败处置与应用层双向结果。

先把文本状态说清楚

IETF Datatracker 已把第 11 版列为旧版本。第 12 版在 4 月跟进，现行第 13 版发布于 2026 年 7 月 4 日，将于 2027 年 1 月 5 日到期。它的目标状态是 Proposed Standard，但 IESG 状态仍为“I-D Exists”，也没有负责的 Area Director、文档 shepherd 或 telechat 日期。

版本变化并非排版修订。第 13 版把消息子类型 2 从 new_key_update 改名为 key_update_finish，进一步说明三条消息都由旧应用密钥保护，并扩展了主动攻击者的边界。因此，实施声明必须同时写出草案版本和实际观测行为。

协商成功不等于更新成功

客户端在 ClientHello 的 TLS flags 中提出 Extended_Key_Update，服务器只有在支持且启用时才在 EncryptedExtensions 中确认。没有确认，本会话就不存在该能力；若应用确实要求后妥协安全，只能另行完成一次完整握手。

一旦双方协商 EKU，普通 KeyUpdate 反而被禁止，收到它必须以 unexpected_message 终止连接。请求和响应还必须沿用初始握手选定的密钥交换组；中途换组不是算法敏捷性，而是 illegal_parameter。

这意味着“软件版本支持”“策略已经开启”“本会话已协商”是三件事。任何一个字段都不能替代其余两个。

一个交换，四种临时视图

发起方先发送带新 key share 的 key_update_request。响应方返回 key_update_response 后先切换发送密钥。发起方收到响应、派生新秘密、切换接收密钥，再用旧密钥发送空的 key_update_finish，之后才切换发送密钥。响应方只有在旧密钥下认证 finish 后，才能切换接收密钥。

于是，短暂的方向不对称是设计的一部分：一端可能已经用新密钥发送，却仍用旧密钥接收；另一端恰好相反。单一的“连接密钥版本”会抹掉最关键的状态。

若双方同时发起请求，以 key_exchange 的字节序比较解决竞争，较小者落败；完全相等则违反协议并关闭连接。只记录“开始/完成”的监控无法解释哪个请求存活、哪个方向先前进。

新输入改变了密码学主张

第 13 版把新计算的共享秘密、从既有 main secret 派生的值，以及覆盖初始握手和历次 EKU 的 transcript hash 一起输入派生过程。随后生成客户端和服务器的应用流量秘密、exporter secret 与 resumption main secret。这正是它强于普通 KeyUpdate 的地方：下一代状态不再完全由已泄露的旧链决定。

但网络跟踪只能看见 key share 和可兼容的新记录，无法证明随机数发生器健康、临时材料从未重用，也无法证明堆内存、HSM 槽位、内核卸载区或崩溃转储中的旧副本已消失。草案要求实现应尽快删除旧秘密；远端对端无法替本地存储作证。

因此，真正的操作对象是一组可关联、但不泄漏秘密的回执：协商版本与密钥组、临时材料的非秘密代次标识、request/response/finish 标识、后继秘密代次、各存储层销毁结果，以及两个方向首次接受新密钥记录的时间。

攻击者必须先离场

草案的恢复主张针对短暂妥协。只有当攻击者在新交换发生时已失去对两端的访问，保密性才可能恢复。持续控制终端的攻击者可以直接读取新状态；仍掌握当前流量密钥的主动攻击者还可能替换 EKU 消息并维持中间人位置，除非执行第 11 节所述的附加认证。

握手后证书认证和修改后的 Exported Authenticator 可以把认证结果绑定到 EKU 之后的状态，但其可用性、策略、执行、对端身份和成功结果都要单独观测。恢复一条连接也不等于修复被盗的长期身份私钥，未来握手仍可能遭到冒充。

DTLS 1.3 还引入丢包、乱序、重传、ACK 和旧 epoch 暂存。发起方收到新 epoch 的确认后才完成发送切换。TLS 流式连接的仪表板不能只换一个协议标签就用来证明 DTLS 恢复。

来源