2026 年 7 月 6 日，Daniel J. Bernstein 发布了他「NSA and IETF」系列的第 8 篇博文，标题只有一个词：Fairness。这距离他上一次在该系列中「数票」（part 7, Counting votes）刚好过去三个月。而这一次，他不再数票——他在数那些被忽略的人。
djb 不需要太多介绍。Curve25519、Ed25519、NaCl、qmail、djbdns 的作者，在密码学和安全工程领域的声誉源于他三十年如一日的「固执」：对每一个安全假设穷追猛打，对任何形式的「权威说了算」零容忍。从 2022 年起诉美国政府要求公开 NSA 与 NIST 后量子加密标准化的幕后文件开始，他就没打算让这个话题冷下来。这次，他把矛头对准了 IETF 的程序本身。
一个 RFC，两套方案，三年的拉锯
争议的核心是一份 IETF 草案（draft）：draft-ietf-tls-mlkem。这份草案定义了如何在 TLS 1.3 中单独使用 ML-KEM（后量子密钥封装机制）进行密钥协商——不做双层加密，不保留传统的椭圆曲线层，纯后量子。
与之对应的是另一份草案 draft-ietf-tls-ecdhe-mlkem，定义混合模式（hybrid）：将传统的 ECC（椭圆曲线密码）与 ML-KEM 叠在一起，两层独立加密。即使后量子层被攻破，ECC 层仍在。djb 喜欢用一个比喻：ECC 是安全带，ML-KEM 是安全气囊。你不需要在安全气囊和安全带之间二选一——两个都配上才是常识。
现实中，混合模式已经是 TLS 后量子迁移的事实标准。Cloudflare 观测到，截至 2025 年 9 月，接近一半的 HTTPS 连接已经在使用 ECC+ML-KEM，其中 95% 是 X25519MLKEM768。没有人反对混合模式。争议的焦点是：有没有必要单独为「不系安全带」建一个官方标准？
支持方说：有。NSA 的 CNSA 2.0 合规时间表要求到 2033 年全面使用 FIPS 203 级别的纯 ML-KEM，混合方案在合规框架下存疑。O-RAN、IEEE 802.11、3GPP 等标准组织已经发来联络函，要求 IETF 提供一个稳定的纯 ML-KEM RFC 作为规范性引用。
反对方说：这正是问题所在。一份 RFC 不是中立的「技术文档」——它带着 IETF 的共识背书。一旦发布，采购经理会拿着它写招标要求，政府合规清单会引用它，厂商会围绕它做产品。历史上，Dual EC 也是「仅供参考」的随机数生成标准，直到 NSA 花了钱让它变成默认选项。
第三次「last call」——谁被遗漏了？
djb 这篇博文的核心指控是程序性的。他用了一组数字把问题讲清楚：
在第二次「last call」（2026 年 2 月）中，22 个人提交了正式反对意见。三个月后，WG chairs 宣布「重大进展已回应了上一轮 WGLC 中提出的关切」，并以此为依据发起了第三次投票。
djb 逐一核对了这 22 个人的反对内容：
- chairs 的回应只覆盖了其中 3 个人的关切（#1, #2, #3）。这三人随后表示立场变为中立、中立和支持。
- 15 个人的反对明确涉及安全问题——即 solo ML-KEM 相比 hybrid ECC+ML-KEM 的安全风险（#4–#8, #10, #12, #13, #15–#20, #22）。这些安全异议没有被触及。
换言之，第二轮反对者中近七成的人提出的安全关切，在第三轮投票启动时被原封不动地跳过了。chairs 声称「关切已被回应」——djb 认为这是撒谎。
这些被忽略的反对者不是无名之辈。Orr Dunkelman，AES 已知最佳攻击的发明者之一；Peter Gutmann，cryptlib 作者；Fabiana Da Pieve，欧盟委员会后量子密码团队负责人。他们提交的反对意见在邮件列表里可以公开查阅，但他们的声音没有被纳入 chairs 的「共识」计算。
「rough consensus」的非对称陷阱
djb 揭示了一个 IETF 流程中深刻的结构性不对称。
如果 chairs 在「last call」后宣布「rough consensus」——草案就通过了。工作组的工作结束，文档提交给 IESG，在绝大多数情况下被橡皮图章通过（IESG 的多数成员本身就是国防承包商，外加一位 NSA 出身的 Deb Cooley）。发布的 RFC 上会印着「IETF 社区的共识」，不带「rough」的限定词，不标注任何反对意见的存在。
如果 chairs 不宣布 consensus——什么都没结束。规则中没有条款阻止 chairs 在几周或几个月后发起第四次、第五次「last call」。这就是为什么 ietf-tls-mlkem 已经在经历第三次投票。
djb 把这种机制描述为「内建的亲通过偏见」（pro-endorsement bias）。对于有大公司背景、能派 100 人到每次 IETF 会议的参与者而言，持续重投只是资源消耗。对于代表公共利益、没有机构资源支撑的个人研究者而言，每一次重新组织技术论证、回复邮件列表、跟踪投票进展都是沉重的负担。
还有一个细节耐人寻味。chairs 在发起第三次投票的邮件中承诺：如果本次没有 rough consensus，「我们将停止讨论这份草案，不再推进」。但 djb 指出，同样的 chairs 在 2025 年 2 月曾承诺会发起 ECC+PQ 签名的 TLS 采纳流程——这个承诺至今没有兑现。IETF 的规则体系中，没有机制能强制执行 chairs 的「承诺」。
谁在投票，谁在观战
选举式投票本身就不符合 IETF 的规则。IETF 明确规定参与「对所有人开放」，分歧「必须通过公开评议和讨论来解决」。但在第三次「last call」的邮件列表上，讨论已然沦为一场政治动员。
djb 列出了一份支持方名单：NSA 的 Mark Motley、Mike Jenkins、Nicholas Gajcowski，GCHQ 的「Flo D」「Michael P」「Peter C」，Cisco 的 David McGrew、Eliot Lear、Scott Fluhrer，Google 的 David Adrian、David Benjamin、Sophie Schmieg。60 多人提交了反对意见，而支持方试图用各种论证阻止这个数字增长。
HN 上的讨论提供了更完整的画面。tptacek（Thomas Ptacek）指出，ML-KEM 并非 NSA 设计——它来自一批受尊敬的欧洲学院派密码学家，包括 djb 本人的前合作者 Peter Schwabe，且通过了一个 djb 也曾参与提交算法的公开竞赛。他还指出，混合 TLS 早已是主流，这份草案只是「记录了纯 ML-KEM 的可能性」。
但 chrismorgan 的反驳也值得注意：「人们已经在这么做了，所以我们不如盖个章」——这条论证路线本身有风险。RFC 的背书效应会造成使用量的正反馈，让原本可能谨慎的选择变成系统性的默认行为。W3C 失去对 HTML 的控制也许不是坏事，但密码学标准如果失控，后果的严重性远不是一个层级。
欧洲的立场也在 HN 讨论中被引用。德国 BSI 的技术指南明确表示「后量子机制尚未被信任到与经典机制同等的程度」，因此推荐混合模式。法国 ANSSI 的立场文件同样强调「后量子算法仍不够成熟，不能单独保证安全」。两家欧洲主要网络安全机构——与美国 NSA 关系复杂的盟友——都站在了 djb 一边。
NSA 的历史与现实的交错
djb 的系列博文有一个贯穿始终的论证：NSA 的历史行为是机构使命的体现，不能简单归结为「过去的错误」。他在 part 8 的开篇又快速回顾了一遍：
1970 年代，NSA 暗中削弱 DES 至 56 位，同时公开声称自己也会使用它。1990 年代，NSA 利用出口管制例外条款，推动 RC4 和 RSA-512 的广泛部署，造成了持续数十年的安全问题。2000 年代，NSA 破坏随机数生成器标准，并直接付钱给 RSA 公司将其设为默认选项。2010 年代，NSA 拥有每年 2.5 亿美元的预算，专门用于「隐蔽地影响和／或公开地利用」标准，使其「可被利用」同时让「消费者和其他对手」以为「系统安全完整」。
这些事实不依赖于雪登的爆料——越来越多的历史档案通过 FOIA 诉讼被公开。djb 本人就在推动这些诉讼。
支持 solo ML-KEM 的一方则有不同的叙事。他们认为，djb 过度捆绑了历史与当下：ML-KEM 的设计团队和评审过程与 DES 或 Dual EC 完全不同，将 NSA 的历史罪责映射到一份纯粹的技术草案上是逻辑跳跃。更何况，混合模式草案已经被工作组采纳，没有人阻止任何人使用混合方案。问题仅仅是：是否要阻止纯 ML-KEM 获得 RFC 编号。
djb 对此的回答是迂回的但有力的：如果纯 ML-KEM 真如支持者所言「不会影响任何人」——如果 Sophie Schmieg 声称它只会被 NSA 自己使用——那么延迟它也不会伤害任何人。但如果反对者是对的，安全风险是真实的，那么阻止它就是在保护数百万用户。两种错误的后果完全不对等。
TLS 生态会被改变吗？
从社区讨论来看，这场争议的短期实际影响可能比双方声称的都小。
IANA 已经为纯 ML-KEM 分配了 TLS 密码套件代码点。各种 TLS 库（BoringSSL、OpenSSL 等）已经实现了纯 ML-KEM 支持。即使 IETF 拒绝发布 RFC，草案作者也可以通过「独立提交」（Independent Submission）路径发布文档——这个路径不受 IETF 共识流程约束，就像 GOST 的 RFC 9367 一样。
但符号层面的重要性不容忽视。一份印着「IETF 共识」的 RFC，与一份独立的 Informational RFC，在法律引用、政府采购、行业合规中的分量完全不同。这正是 djb 在 part 7（“A standard by any other name”）中深入讨论的问题：IETF 试图用「这只是一个描述性文档」的说辞来否认其标准的事实效力，但外部世界并不这样解读。
更深层的问题是技术治理的合法性。如果 IETF 的「rough consensus」可以通过持续重投、忽略安全异议、依赖企业投票人数来达到，那么这个流程是否在执行它声称的功能——「找到对整个互联网最好的解决方案」？
djb 在他的反垄断法律论证中触及了这一点：美国联邦法律（15 U.S.C. §4302）为标准化组织提供了反垄断豁免，前提是它们遵循「共识」程序。如果 IETF 的实际操作偏离了法律定义的「共识」——让异议被系统性地压制、让投票替代技术讨论——这个豁免的基础是否还在？
HN 上的法律讨论对此有分歧。有评论者指出，IETF 的流程早于这部法律十多年，且该法律的所有判例都针对美国国内的标准制定组织（如 ASME、NFPA、ANSI），而 IETF 是一个全球范围的机构。但也有评论者认为，由于 IETF 的法律实体在美国境内，这一论证并非无的放矢。
围绕 ietf-tls-mlkem 的第三轮投票将于 2026 年 7 月 8 日结束。无论结果如何，djb 已经说得足够清楚：在一个不对称的流程中，沉默等于投票支持推进。他这篇博文的实际目的，是让那些犹豫不决的人意识到，投下反对票的唯一代价是延迟，而投下赞成票或在沉默中旁观的风险，是对安全标准可信度的侵蚀。
这是一个开放的技术治理问题：当「共识」的定义权掌握在 chairs 手中，当参与的资源门槛天然偏向大公司和政府机构，当安全异议可以被无休止地「重投」消耗掉——标准制定流程还能不能有效代表公共利益？
参考链接
- djb: NSA and IETF, part 8: Fairness
- djb 系列前文索引（parts 1–7, “A standard by any other name”, “Understanding lattice risks”）
- IETF TLS WG: draft-ietf-tls-mlkem
- HN 讨论（110 分，90 条评论）
- NIST FIPS 203 (ML-KEM)
- BSI 后量子密码技术指南
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。