摘要

  • IESG 于 2026 年 9 月 3 日批准 draft-ietf-uta-tls13-iot-profile-25 成为 Proposed Standard；当时公告尚未给出最终 RFC 编号。
  • 新文件为受限物联网设备规定 TLS/DTLS 1.3 配置，只更新 RFC 7925 的 X.509 证书配置和密码套件部分，并未让长期运行的 TLS/DTLS 1.2 设备失去现实意义。
  • 草案直接写明：协议兼容是必要基础，却不足以实现认证与授权层面的互操作。
  • 证书、裸公钥和外部预共享密钥各自带来不同的身份绑定、配置和生命周期责任；完成握手不等于设备获得执行某项操作的权限。
  • 运营方应保存一份版本化“授权边界收据”，连接凭据方式、预期对端、本地权限、信任锚、会话年龄、重新认证、错误处置与回滚，同时不公开密钥和敏感设备资料。

批准的是共同底座

这次 Protocol Action 是正式的标准流程结果。Using TLS in Applications 工作组给资源受限设备整理出一套 TLS 1.3 与 DTLS 1.3 共同行为：支持哪些凭据和扩展，如何处理告警、会话恢复、前向保密、定时器、记录大小、证书以及密码套件。IESG 认定文本获得广泛支持，并批准其进入 Proposed Standard。

共同底座解决的并非小问题。如果芯片厂商、设备制造者、云端服务和采购方各自理解“支持 TLS 1.3”，两个实现即使都能发送报文，也可能在必要扩展、证书字段或凭据模式上无法协作。配置文件把这些要求收束成可检查的范围。

但同一份文件没有把自己的影响无限放大。第 25 版明确说，TLS 协议兼容仍不足以带来认证与授权的互操作。它能说明某个密钥在一次协议上下文中得到验证；它不能替运营方决定这个密钥是否对应预期设备，也不能决定该设备是否有权读取测量值、修改参数或触发动作。

状态也要分清。IESG 已批准 Proposed Standard，公告时尚无最终 RFC 编号，RFC Editor 后续仍可能进行编辑。这不削弱批准，只防止把“获批文本”“已出版 RFC”“Internet Standard”与“产品认证”混成一个标签。

与 RFC 7925 的关系同样有限。新文档并非全面取代旧的 TLS/DTLS 1.2 配置，只更新证书和密码套件要求。工业设备、认证项目和运维流程寿命很长，迁移速度低于通用软件。一个实际设备群可能长期同时存在多代协议；资产清册必须记录每台设备适用的配置版本。

三种凭据，三条尚未闭合的链

配置文件覆盖证书、裸公钥和外部 PSK，并有意不指定唯一优胜者。安全特性、成本、设备能力和运营条件会改变选择。

X.509 证书通过签发链把公钥和标识符联系起来。草案借用 IDevID 与 LDevID 的区别：制造时写入的初始设备身份通常服务于引导和入网，部署后由所有者或运营者配置的本地设备身份才用于具体运行环境。初始凭据可以帮助获取运营凭据，却不应因为更换困难就自动继承长期操作权限。

裸公钥省去证书链的字节，但身份含义要在协议外补上。草案要求部署把已认证公钥绑定到预期对端。当客户端因固定公钥、固定证书、地址或 PSK 身份而不发送 SNI 时，也必须存在另一条绑定。否则，系统可能精确验证了“这把钥匙”，却错误回答了“这是谁的钥匙”。

外部 PSK 把更多权力放在带外配置流程：密钥身份、熵、适用域、版本隔离和替换都不是握手现场产生的。草案要求在可能时使用 (EC)DHE 来获得前向保密；只有部署明确接受失去这项性质时，才可采用纯 PSK。所谓“明确接受”应有负责人、范围和到期日，而不是设备出厂后无人记得的一项开关。

SNI 可以帮助选服务或证书，ALPN 可以区分应用协议。二者都不能颁发权限。草案明确把授权放在已认证凭据与本地策略的结合处。知道对端要求 MQTT、CoAP 或某个云端名称，不代表它可以执行应用操作。

不做在线撤销检查，责任就会上移

许多受限设备没有资源在握手中查询 OCSP 或 CRL。第 25 版没有假装撤销因此不重要，而是描述另一种常见安排：短寿命运营证书、自动化入网与管理，以及运营者负责下发更新。

这种安排有一只不能忽略的时钟。证书到期或被替换，并不会自动终止已经建立的长会话。TLS 不要求连接建立后持续检查证书状态。如果业务需要持续有效性，应用就必须主动重新认证，或者断开并重建连接。相互的握手后认证还需要应用协议承载额外机制。

于是“新证书已发放”与“旧授权已消失”成为两个不同事实。中间可能仍有用旧凭据建立的会话。把撤销责任交给运营方，不是降低安全要求，而是指明谁必须关闭这个时间差。

信任锚的寿命更长。长期部署的设备会遇到 CA 轮换、厂商变化、算法迁移或事故处置。固件更新或证书管理协议可以传送新锚，但传送不等于启用。可核验记录应区分计划、送达、安装、选择、实际观察和旧锚退役，并把无法联系的设备留在分母里。

每一次省字节都会移动控制面

草案给出一个直观数字：在采用小型椭圆曲线证书、没有下级 CA 的双向认证示例中，两张证书约占 TLS 1.3 握手载荷的 40%。缩短证书链、压缩、缓存和会话恢复都能省带宽和计算，但没有免费选项。

会话票据的数量、有效期与复用规则，需要在服务器状态、抗重放和隐私之间权衡。把证书放到外部地址下载可以减少握手包，却增加 DNS 或目录依赖，也可能向检索服务暴露稳定标识。缓存节省重传，同时产生失效判断。无线链路少用的每个字节，都可能让另一个组件承担更多新鲜度与可用性责任。

0-RTT 的边界最清楚。应用协议没有自己的使用规范时，不得启用 0-RTT；该规范还必须说明哪些消息安全，以及服务器拒绝后怎样退回 1-RTT。第 25 版称当时 CoAP 与 MQTT 都没有这种配置，所以本文档没有替它们启用 0-RTT。传输层“能早发”不等于应用层“有权早发”。

告警也需要本地规则。无人值守设备无法弹窗征求同意。应用必须预先决定哪些错误可以重试，何时切换端点或凭据，何时进入安全运行状态。TLS 库提供协议事实；设备可能造成的现实后果由部署者负责。

一份不暴露秘密的授权边界收据

收据先记录所依据的配置文件版本与实现构建，再记录凭据模式、稳定凭据引用、预期对端、绑定方法、应用协议与角色、本地授权策略版本，以及允许或拒绝的操作类别。

生命周期栏记录信任锚代次、证书或 PSK 代次、配置渠道、激活证据、到期和替换状态。会话栏区分完整握手与恢复握手，记录票据代次、会话开始、最近重新认证和允许的最长会话寿命。若部署接受纯 PSK 的前向保密损失，例外的所有者、范围与到期时间也必须存在。

安全处置栏把关键告警连接到重试、替代路径、降级模式或安全停止。0-RTT 应明确标为禁用；未来若有应用配置允许，则记录所覆盖的消息类别和抗重放状态。收据无需包含私钥、完整证书、精确内部拓扑或可复用攻击步骤。

更新记录应追加而非覆盖。信任锚、证书或策略变化后，旧状态仍是解释既有会话的依据。只有当前值的仪表盘能告诉人今天允许什么，却无法回答昨天的设备为何获准进入。

这里对 Heng Lu 第 64 号笔记的使用是有限的：共同规则应保持最小、确定且可在本地验证。这不是有关某个设备群的证据。它提示的是，IETF 无需替每个运营方写同一套权限表；同时，运营方也不能让一项不可见的本地决定借用共同标准的权威。

这次批准没有证明什么

现有来源没有证明任何具名产品符合第 25 版，没有审计某个设备群，也没有报告事故。IESG 没有选择运营者的 CA、PSK、权限表或安全停机动作。Proposed Standard 不是产品徽章。

该文件也不是后量子配置。规范性密码套件仍基于经典密码学；PQC 一节只是部署提示，不增加规范要求。设备寿命很长，意味着迁移计划很重要，不意味着迁移已经完成。

同样，文档没有说所有设备永远不能做 OCSP 或 CRL 检查。它描述常见限制并建议逐案权衡。资源足够、风险不同的设备可以选择更直接的机制。

这次批准的真正价值，是把共同问题压缩到更清晰的底座，并让剩余责任无处躲藏：IETF 规定可互操作的握手；现实中的授权仍由承担后果的人作出。

来源

  1. IESG：物联网 TLS/DTLS 1.3 配置文件批准公告
  2. IETF：获批的第 25 版草案
  3. RFC 9846：TLS 1.3
  4. RFC 9147：DTLS 1.3
  5. RFC 7925：物联网 TLS/DTLS 配置
  6. RFC 5280：X.509 PKI 证书与 CRL 配置
  7. RFC 9257：外部 PSK 指南
  8. RFC 9258：外部 PSK 导入
  9. RFC 9019：物联网固件更新
  10. RFC 8995：BRSKI
  11. RFC 9525：TLS 服务身份
  12. RFC 9325：TLS 与 DTLS 安全使用建议
  13. Heng Lu：Minimum Initial Specification