摘要

  • Rich Salz 与 Nimrod Aviram 合著的 RFC 9852 / BCP 195 要求：使用 TLS 的新协议应当假定 TLS 1.3 可用，并把 TLS 1.3 规定为默认值。这项规则约束的是正在编写的协议规范。
  • 规范要求不是运行端点发出的部署回执。实际协商的版本、端点配置、对端认证、应用接受结果和恢复记录仍是不同事实。RFC 也明确不把这一规定适用于任何版本的 DTLS。

标准里的“必须”很重要。它让新协议的作者不能把已经有明确方向的技术选择伪装成中性的选项。不过，规范性要求并不是一次现场测量。如果一份 RFC 写明 TLS 1.3 为默认值，不能据此跳到“某项服务已用 TLS 1.3 部署”的结论；文档没有观察那项服务的连接。

RFC 9852《New Protocols Using TLS Must Require TLS 1.3》是 IETF 的最佳现行实践 BCP 195。Rich Salz 与 Nimrod Aviram 被列为作者，但它是 IETF 共识的成果，不是某一作者对外部系统作出的运行声明。它回答的是一个窄而重要的问题：新协议如果使用 TLS，应该在规范中写什么？答案是应假定 TLS 1.3 可用，并将其设为默认值。

这并没有替端点做完后续的工作。某项协议可以完全遵守该设计规则，而运维方仍需知道某个客户端与某个端点实际协商了什么版本；本地策略最终选择了什么；服务所需的证书和对端认证是否成功；握手之后应用是否接受该连接；发生异常时又是否被发现和恢复。它们由不同主体控制，也需要不同证据来说明。

DTLS 的界线尤其不能省略。RFC 9852 说该规定只针对 TLS。由于 DTLS 1.3 尚未被广泛提供或部署，要求不适用于任何版本的 DTLS。把全文压缩为“TLS 1.3 已强制”会把规范专门留下的边界抹掉，并把针对新 TLS 协议的判断错误扩展到数据报场景。

RFC 给出设计理由：TLS 1.3 已被广泛使用，拥有全面的安全证明，并改善 TLS 1.2 的安全和隐私不足。它也承认 TLS 1.2 经过合适、往往是定制化的配置，仍可以具备良好安全属性。后量子迁移是推动方向的考虑之一，但某个具体应用何时需要 PQC 则被明确排除在文档范围外。这些理由支持一条规范规则，不构成任何系统的遥测报告。

运行代码优先原则要求把这些证据保留为独立连接。BCP 证明设计的要求；配置记录证明某个端点的意图；握手观察证明某一次连接的协商；认证、应用处理和恢复记录各自证明另外的事实。把它们都塞进“符合 TLS 1.3”的一个状态，反而会使故障发生时无人知道哪一环真正被验证。

因此，协议作者应按 BCP 195 写清默认值；运维方应仅在可以检查相关端点的策略、协商、必要认证、应用结果和恢复链路时报告部署结果。规范与运行系统由此可以互相支撑，而不互相冒充。

来源