NSA 和 IETF：公平性

原文 ↗ Hacker News 讨论 ↗

争议范围

  • 讨论聚焦于 IETF 的 TLS 工作组是否应发布一份信息性 RFC，描述在 TLS 中纯 ML-KEM 的使用（不采用与 ECC 的混合后量子 KEM），以及这一流程是否公平。
  • 文章作者是这一流程以及 ML-KEM 的核心批评者，但讨论范围更广，涉及标准治理、NSA 的影响，以及 PQC 的成熟度。

IETF 流程：“粗略共识” vs “投票”

  • 有人认为把工作组决策称为“投票”具有误导性，并削弱了对程序的异议；IETF 明确是通过“粗略共识”运作，而不是按人数计票。
  • 也有人指出，实际中主席和流程仍可能被操纵，但认为关于“共识”和反垄断豁免的法律论点被夸大了，或在法律上显得天真。
  • 还有人担心，对 IETF 的严厉批评会疏远那些仍然认为它总体上做得不错的人，尽管其中确实存在一些不良行为者。

TLS 中 ML-KEM 的状态

  • 仅使用 ML-KEM 的命名组已经有 IANA 代码点；该草案主要规定如何在 TLS 中使用它们，并标记为“recommended = N”。
  • ECC+ML-KEM 的混合方案已经标准化并被推荐；争议在于是否要把 纯 ML-KEM 作为一种选项记录下来。
  • 有人说根本没必要通过 IETF 来推进：任何公开规范都足以支撑代码点，而理论上也可以采用独立的 RFC 流程。

安全性、成熟度与侧信道问题

  • 一方认为：像 ML-KEM 这样的格基 KEM，就其年龄而言，研究程度与 ECC 变成主流时相当；ML-KEM 具有形式化分析、部署历史，而混合 TLS 已经被广泛使用。
  • 另一方认为：PQC（尤其是 ML-KEM）更新，且存在明显实现缺陷（例如 KyberSlash 的时序泄漏）；构建稳健的、抗侧信道的实现技术仍不成熟。
  • 有人强烈批评 FIPS 203 和 ML-KEM TLS 草案把抗侧信道能力当作可选的“建议”，而不是规范性要求；并将其与一些过去 RFC 中更具体的指导形成对比。
  • 一些人认为标准应当明确具备误用抵抗性，并避免诸如强大但易受侧信道影响的“踩坑点”。

混合方案 vs 纯 ML-KEM

  • 支持混合方案的观点：鉴于 PQC 的成熟度和侧信道行为仍不确定，PQ 应该是在现有 ECC 上“加上去”，而不是替代它；一些欧洲政府指南明确建议在短中期采用混合方案。
  • 对混合方案持怀疑态度的观点：对于设计良好的方案，ECC+ML-KEM 带来的实际收益很有限（类似把强密码套强密码），却增加了复杂性；并且已有形式化证明表明，即使 ML-KEM 失败，某种混合方案仍然是安全的。
  • 还有人指出，某些环境（例如电信）据说“必须”使用纯 ML-KEM，因此记录它有助于互操作性，而不是强制使用。

NSA 的角色与对标准的信任

  • 一派强调 NSA 在历史上的角色：在 DES 中推动更弱的密钥长度、Dual_EC_DRBG 后门事件、1990 年代出口限制，以及当前机密的 Suite A 算法，都是让人深度怀疑的理由。
  • 另一派反驳称：
    • ML-KEM 是由学术团队设计的，而不是情报机构。
    • 国家标准机构与信号情报机构是不同的实体，激励有时还会冲突（进攻 vs 防御）。
    • NSA 自己在高机密级别采用 ML-KEM，说明其对该方案有信心，而不是刻意植入后门。
  • 少数人认为，情报机构反对混合方案的模式本身就可疑，因此有理由极度谨慎。

发布（或不发布）RFC 的影响

  • 有人认为，发布一份状态为“not recommended”的信息性 RFC 只是反映现有实践，并支持其他曾发来联络请求、希望获得稳定参考的 SDO（例如电信和无线机构）。
  • 另一些人认为，任何 RFC，即使只是信息性，也会带来“RFC 光环”，并增加部署，尤其是在纯 ML-KEM 可能是不必要或不安全风险的场景中。
  • 对于“已经有人在用”是否是标准化的正当理由，还是为可疑做法盖章，双方存在分歧。

流程操纵与 brigading

  • 多条评论指称，反对纯 ML-KEM TLS 的批评者对 TLS 邮件列表进行了协调式“brigading”，包括模板化的主题行，以及号召人们专门加入来反对该草案。
  • IETF 参与者重申，表面上的“票数”并非决定性因素；有力的技术论证和实现者共识可以压过原始人数。
  • 如果工作组拒绝发布，该 ML-KEM 代码点仍然有效；主要区别只是失去一份正式绑定 TLS 的 RFC。