摘要

  • 2026 年 9 月 3 日，IESG 宣布批准 draft-ietf-tls-mlkem-10 作为 Informational RFC 发布；它把 ML-KEM-512、768 和 1024 定义为 TLS 1.3 的纯后量子 NamedGroup。查阅时尚未分配 RFC 编号。
  • 三个条目的 DTLS-OK 都是 Y，Recommended 却都是 N。RFC 9847 明确规定：N 既不是推荐，也不等于有缺陷或被劝阻使用。文件状态、注册表状态、端点配置、实际协商与业务结果必须分别留证。

把正式批准看成部署命令，只需要忽略注册表中的一个字母。把 N 看成禁止使用，也只需要忽略同一个字母的正式定义。第 10 版 ML-KEM 草案最值得关注的，不是后量子标签，而是它同时堵住了这两条捷径。

这份文件的技术动作很具体。ML-KEM 先由 KeyGen 生成公开封装密钥和秘密解封装密钥。服务器用 Encaps 根据公开密钥生成密文与共享秘密；客户端用 Decaps 从秘密密钥和密文恢复同一个共享秘密。

草案把这套结构嵌入 TLS 1.3 现有的 supported_groups 与 key_share。编号 512、513、514 分别代表 MLKEM512、MLKEM768、MLKEM1024。客户端在 ClientHello 的 key_share 中发送公开封装密钥；服务器在 ServerHello 中发送密文；双方得到的 32 字节共享秘密进入 TLS 密钥日程，取代通常的 (EC)DHE 共享秘密位置。

三个参数集并不只是名字不同。ML-KEM-512 的公开密钥为 800 字节、密文为 768 字节；ML-KEM-768 分别为 1,184 和 1,088 字节；ML-KEM-1024 的两项都是 1,568 字节。它们是协议尺寸，不是某个网络的时延、分片、容量或成功率证据。

错误路径同样被规定。服务器必须执行 FIPS 203 的封装密钥检查，失败时以 illegal_parameter 中止。客户端必须核对密文长度是否符合所选参数集，长度错误也返回 illegal_parameter；其他解封装失败以 internal_error 结束连接。TLS transcript 包含 key share 字段，因此会把封装密钥和密文纳入握手承诺。

线格式完整，并不意味着实现自动可靠。草案禁止重复使用生成密文的随机性，也就禁止复用 ML-KEM 密文。它还指出一个容易漏掉的信任方向：持有解封装密钥的一方可以精确恢复封装随机量。如果随机数生成器不安全，而一次输出会泄露其他输出或内部状态，那么对端能够获得这种信息。

FIPS 203 定义算法；NIST SP 800-227 和 RFC 8937 给出 KEM 与随机数使用指导。这些文件都不能证明某个 TLS 二进制、硬件模块、熵源、进程复制后的 reseed 行为或旁路防护。形式化分析可以证明构造在假设下的性质，不能替运行中的实现签收。

再看注册表。2026 年 9 月 5 日查阅 IANA TLS Supported Groups 时，512、513、514 已经出现，三个条目均为 DTLS-OK=Y、Recommended=N。引用列仍指向更早的个人草案第 05 版；与此同时，Datatracker 显示第 10 版已经发出批准公告，IANA 动作为进行中。这是一份带时间戳的投影状态，不能被写成永久缺陷，后续必须重新核对。

两列的 Y 与 N 也不能合并成一个颜色。DTLS-OK=Y 回答该组是否可用于 DTLS 这一注册字段的问题。它不回答 IETF 是否推荐一般部署，不回答某个产品实现是否正确，更不回答某支设备群是否应该启用。

RFC 9847 为 Recommended 定义了三种含义。Y 表示 IETF 已形成共识，认为条目适合其定义的用途，但仍要阅读适用范围。D 表示不鼓励使用，并要求引用或评论说明原因。N 表示 IETF 没有对适用性作出声明；原因可能是尚无共识、适用范围有限或使用条件受约束。它不必然表示机制有缺陷。

因此，“批准发布”不能被洗成“推荐默认开启”，“Recommended=N”也不能被洗成“安全禁止”。前者借用机构权威替本地负责人作决定，后者发明了一项机构没有作出的否定判断。两种说法都省掉了最关键的责任人。

RFC 10024 的混合组提供了有用对照，但不是本篇的结论。当前表中，X25519MLKEM768 为 Recommended=Y，另一些混合组仍是 N。纯 ML-KEM 草案要求实现者根据安全、性能和运营约束，在纯构造与混合构造之间自行评估；它没有宣告所有场景的统一胜者。

一次可审计的部署决定至少需要十层收据：查阅的文件版本、当时的 IANA 行、库和加密模块版本、随机数与 fork/reseed 控制、各终止点的配置顺序、ClientHello 实际提议、ServerHello 实际选择、参数检查和中止原因、握手完成记录、应用请求与响应。例外负责人、回滚触发器和复查日期也应进入同一台账。

每层证据都不能越权。配置只证明意图；提议不证明选择；选择不证明握手完成；握手不证明应用可用，也不证明业务身份或权限；一台 canary 的结果不证明全网，除非明确设备群、路径与观察窗口。

Lu Heng 的 running-code 原则在这里并不反对标准，而是限制标准被滥用。最小共同规范负责让参与方对字节、编号和失败行为达成一致。本地运营者负责是否开启、如何试验、何时回滚，因为兼容性、容量与安全后果最终由它承担。现实分层则要求批准文件、注册表行和真实流量各自说自己能证明的事实。

三个纯 ML-KEM 组现在已有可实现、可协商的公共描述，这是重要进展。N 没有抹去这种进展，也没有补上一份部署命令。它为本地判断留下一个清晰位置：不得冒充 IETF 推荐，也不得冒充 IETF 禁止，只能用可复现的运行证据授权下一步。

来源