摘要

  • draft-ietf-dance-client-auth-14 让 TLS 1.3 客户端提交完整 TLSA owner name，服务器随后查询该名称、验证 DNSSEC，并把记录与证书或裸公钥匹配。
  • 这条链只能形成有限的“名称—记录—密钥”证明；谁在使用名称、分配是否仍有效、客户端能否进入服务、具体动作是否获准以及结果是否发生，都需要其他凭据。

设想一台设备把 sensor7._device.example 放进 TLS Certificate 消息里的 dane_clientid 扩展。服务器不再自行拼接名称，而是直接查询这个完整 owner name。若返回的是经过 DNSSEC 验证的 TLSA RRset，而且其中至少一条记录与握手中出现的证书或裸公钥匹配，TLS 层就得到了一份有价值的证明：对端掌握与该 DNS 记录对应的私钥。

这份证明的边界很窄。DNSSEC 认证的是 DNS 数据；TLSA 匹配认证的是密钥材料。两者都不会自动说明 sensor7 仍属于原来的客户、员工账户尚未停用、设备可以连接这台服务器，或应用应当批准一次控制操作。第14版明确保留服务器自己的 allowlist 与 authorization 规则。换言之，密码学匹配完成之后，真正的业务权限判断才刚开始。

第二次 Last Call 仍在进行

当前依据是2026年9月11日的第14版文本。Datatracker 把它列为 DANCE 工作组的有效 Internet-Draft，目标状态是 Proposed Standard。IESG 于9月15日启动第二次 IETF Last Call，意见截止9月29日。它还不是 RFC，也没有获批、部署或成为强制政策。

评审意见并不一致。Security Directorate 在9月18日给出 Ready，仅提出扩展错误处理引用和裸公钥绑定说明等小问题。DNS Directorate 次日仍给出 Not ready，认为 _service 与 _device 形式没有满足 RFC 8552 对下划线节点名称注册的要求，并质疑 ClientName 的显示格式和255字节解释。报道这项工作时，两个状态必须同时保留。

名称由客户端提交，含义却来自命名制度

服务端 DANE 通常依据端口和传输协议推导 TLSA owner name。客户端身份不存在统一坐标，因此草案要求客户端发送完整名称，服务器不再构造。它举出面向服务、面向设备和自由形式三类名称，但没有规定所有应用都采用同一种语义。

这种安排让 TLS 层保持通用，也把名称治理的责任留在外部。一个标签可以表示人、设备、工作负载或某项服务专用身份。DNSSEC 只能证明该标签下的数据按验证链成立，不能说明标签为何被分配、由谁持续维护，或其现实归属是否仍然正确。

服务器的技术步骤则十分具体。它必须获得通过 DNSSEC 的 TLSA 记录集；无签名答案、不安全委派、验证失败、NXDOMAIN 与 NODATA 都不能产生已认证的记录集。服务器可以直接验证到配置的 trust anchor，也可以通过安全连接信任验证解析器及其 AD bit。失败后，是终止握手还是把客户端视为未认证，仍由策略决定。

DANE-EE usage 3 可以直接匹配证书或公钥，证书里甚至不必包含客户端名称。DANE-TA usage 2 与 PKIX usages 0/1 则还要求 ClientName 出现在证书 dNSName SAN 中，并按 RFC 7671 验证参考身份。裸公钥采用 RFC 7250 的机制，由扩展承担名称传递。不同分支改变认证证据，却没有改变应用授权仍属本地决定这一事实。

九张收据不能压成一张

可审计的实现至少应分别记录：握手收到的 ClientName、实际 DNS 查询与 TTL、DNSSEC 验证器和 trust anchor、TLSA usage/selector/matching type、匹配的证书或 SPKI、名称分配规则、账户或设备归属、服务器 allowlist 版本、应用权限决定，以及最终提交与观测结果。

如果这些阶段只留下“客户端已认证”，失效就会被掩盖。DNS 缓存可能仍有效，而设备管理系统已经重新分配资产；握手可能通过，而服务只允许特定域；会话可能建立，而应用拒绝跨租户操作；动作可能获准，却在下游回滚。每一步都需要自己的时间与责任主体。

TLS 1.3 会加密 Certificate 消息，但服务器随后对客户端名称发起 DNS 查询。未使用加密 DNS 时，人或机器相关名称可能暴露在解析路径上。RFC 9156 的 QNAME minimisation 可以减少高层 DNS 看到的信息，却不能消除权威查询。查询暴露应被评估，但解析器日志本身不是入侵或利用已经发生的证据。