摘要

  • RFC 9934 规定，一份 ECH PEM 文件包含零个或一个 PKCS #8 私钥，以及一个 ECHConfigList；若私钥存在，列表中至少一个公开配置必须与它匹配。
  • 这项规则只证明文件内部关系。进程加载了哪一代、DNS 公布了哪一代、缓存客户端选择了哪一代、ECH 是否接受以及隐私目标是否成立，都是别的证据。

一次轮换可以同时出现四份“正确答案”。密钥系统说新一代已生成，文件检查器说公私钥匹配，权威 DNS 说新列表已发布，客户端却拿着旧缓存发起连接。若服务器已经删掉旧私钥，四条真实记录仍会合成一次 ECH 拒绝。

RFC 9934 解决的是跨 TLS 库传递 ECH 密钥材料的格式问题。它把文件结构压到很小：零个或一个私钥，随后是一个编码后的 ECHConfigList。私钥存在时，必须使用 PRIVATE KEY 标记，按 PKCS #8 PrivateKey 编码；公开部分使用 ECHCONFIG 标记，内容是可放进 HTTPS 资源记录的 ECHConfigList 的 base64 表示。列表中至少有一个 ECHConfig 与私钥对应。

这个约束很严格，却没有越权。它没有说进程一定读取了文件，也没有说服务器选择了哪一个文件。RFC 允许配置多个文件，允许列表中放多个按偏好排序的配置，也允许只取其中一部分作为 retry_configs。一个私钥与一个成员匹配，并不等于活动进程拥有列表里每个配置的秘密能力。

“零个私钥”不是例外漏洞，而是重要边界。公开列表可以单独保存；私钥绝不能随 ECH 参数发布到 DNS。于是同一代配置至少有两份不同权限的制品：供服务器使用的秘密投影，与供客户端发现的公开投影。自动化若把两者当成一个输出，可能泄露秘密；若只靠文件名把两者联系起来，又可能在轮换时错配。

RFC 7468 规定文本边界和标签，并提醒历史解析器对空白等细节并不一致。RFC 4648 让二进制列表能以 base64 搬运。标签、换行和解码成功属于表示层；它们不证明权限、安装、加载或使用。文件名义上属于某个账户，也不证明备份、快照、部署代理和支持人员今天无法读取它。

RFC 9849 把运行时事实拆得更细。面向客户端的服务器应保留当前公布的配置，也应保留客户端因 DNS TTL 或更长缓存仍可能使用的旧配置。服务器解密成功后才能进入 ECH 接受路径；解密失败时会按外层 ClientHello 继续，拒绝 ECH，并可返回较新的重试配置。客户端必须判断是否接受；遭拒的连接不能直接承载应用数据。

因此，轮换不是“覆盖文件”，而是一个有重叠期的分布式状态迁移。生成、部署、重载、权威发布、递归缓存过期和客户端重试各有时间线。旧私钥删得过早，会拒绝仍持有合法旧列表的客户端；旧私钥永不删除，又会扩大秘密保管面和试解成本。

合格的证据包应保存非秘密代号、文件哈希、块数量与顺序、解析和配对结果、真实读取权限、部署与重载回执、服务器活动配置集合、权威 HTTPS/SVCB RRSet、多个递归视角及缓存年龄、客户端收到的列表和选择的 config_id、ECH 接受或拒绝、重试列表哈希、证书验证和 Finished。最后再接一条独立应用观察。审计日志不应复制私钥。

RFC 9848 还说明“接受 ECH”也不能无限外推。混合 ECH 与非 ECH 端点可能被选择性阻断而降级；明文 DNS、IP 地址、流量分析和过小的匿名集合仍可暴露信息。RFC 9460 规范公开服务绑定，却看不到服务器秘密状态。

Heng Lu 的运行代码优先原则，不是让某一个运行进程垄断真相，而是承认每个观察者的权限边界。文件检查器证明文件，服务器证明内存，DNS 证明发布，客户端证明协商，应用探针证明结果。把第一盏绿灯升级为全链路权威，才是应当消除的管理错误。

最小初始规范让公共格式保持薄而可验证。轮换周期、TTL、旧密钥保留、重载方式和隐私目标可以由本地采用者决定。自主决定并不意味着可以省略责任人、观察记录和回滚顺序。

来源