摘要

  • 10 月 27 日的个人 Internet-Draft 修订版让 TLS 1.3 在原有密码套件之外，单独协商 SHAKE256 或 TurboSHAKE256 密钥日程。7 月版本排除了 DTLS 和 Exported Authenticators，新版本为两者补上规则。
  • 握手后认证器如果由 TLS 库外的应用实现，草案要求应用取得实际协商的 KDF 标识，或明确知道未协商新 KDF，同时取得 TLS/DTLS 协议类型。只有 TLS-Exporter 输出的接口不足以完成这次交接。

设想一次采购验收：安全清单读到 TLS_AES_128_GCM_SHA256，便盖章称连接用 SHA-256 计算密钥。这个名字仍会出现，但新版 XOF 草案另加了 schedule_profile 扩展。两端可在不更改密码套件的情况下，改选 SHAKE256 或 TurboSHAKE256 来运行整套密钥派生与握手记录哈希。套件继续决定加密算法；套件名里的哈希却不再管理这部分计算。清单若只看名称，验收的就是铭牌，不是机器。

这次修订的新闻点在边界扩张。7 月的 00 版明确把 DTLS 1.3 和 Exported Authenticators 留在范围之外。10 月的 01 版提出更新四份 RFC，并在第 14.2 节写出握手后认证的算法衔接。RFC 9261允许连接双方在握手结束后再提供身份证明；原有计算使用密码套件关联的哈希。选中 XOF 日程时，新草案改用所选 KDF 的 64 字节 TranscriptHash、相应的导出值和 Finished MAC。没有新扩展时，TLS 1.3原来的 HKDF 路径照旧运行。

问题出在两支团队之间。TLS 库知道握手选了哪个 KDF；应用里的认证器可能只收到 TLS-Exporter(label, context, length) 交来的字节。第 14.2 节要求库外认证器再取得 KDF 标识，或者“没有选新 KDF”的明确结果，还要知道连接是 TLS 还是 DTLS。后者使用不同的内部日程标签。少传这两项，库升级完了，应用仍可能按旧规则制作握手后的认证消息；草案直说结果会是不兼容的认证器。

密钥恢复也要认同一张账。RFC 9258已有独立于密码套件的 KDF 标识体系，新草案要求预共享密钥与会话票据记住其对应 KDF。证书签名则另行协商：换掉密钥日程中的 SHA-2，不会自动换掉签名和证书链里的 SHA-2。Datatracker目前将文本列为个人草案，状态 I-D Exists。原始记录里还没有库外认证器在新 KDF 下通过互操作测试的结果；一次覆盖 TLS 与 DTLS 的 Finished 验证会改变这一判断。