摘要

  • 9 月 5 日发布的 draft-jennings-moq-discovery-01 新增 URI 规范化和 X.509 证书匹配规则；紧随其后的第 02 版只改正了源码仓库链接。经 SVCB 或 SRV 跳转后，TLS 仍须验证原始 moqt URI 的主机，而不是解析出的目标主机。
  • mDNS 发现面对的是另一种权威问题。_moqt._udp、PTR/SRV/TXT 和可识别的 ALPN 可以产生候选中继，却不能证明谁有权发布这条广告。当前草案的安全考虑仍只有 TODO，也没有说明浏览到的服务如何取得可信的原始 URI。

在会场 Wi-Fi 上，“自动发现附近中继”听起来是一项纯粹的便利功能。客户端收到 PTR，找到 SRV 中的主机和端口，再从 TXT 读出 alpn=moqt，几乎可以立即连接。但这条链只说明某台设备愿意这样介绍自己；它没有说明设备属于主办方、获准承载这场直播，或者拥有目标媒体命名空间的发布权。

IETF Datatracker 记录把当前版本标为 2026 年 9 月 5 日的第 02 版。文件名仍是个人草案，记录中没有 IETF stream 或 intended standard level。页眉写着拟走 Standards Track，并把讨论指向 Media over QUIC 邮件列表；这些都不等于工作组采纳、共识或批准。

新闻点来自版本差异。第 00 版在 8 月已经列出 SVCB、HTTPS、SRV 与本地 DNS-SD。第 01 版在 9 月 5 日加入完整的 URI 与证书比较规则。第 02 版随后只把错误的 GitHub 地址换成专用仓库；I-D 公告公布的是一份更清楚但仍在工作的提案，不是上线通知。

解析结果只能决定去哪里，不能决定相信谁

草案为原生 QUIC 使用 SVCB，为 WebTransport 使用 HTTPS，并把 SRV 作为较简单的后备。SVCB/HTTPS 可以携带 ALPN 与连接参数，SRV 只能提供目标和端口。客户端可据此把套接字接到另一台机器。

第 01 版在这里设置了一道必要的边界：SNI 与证书匹配继续使用原始 moqt URI 的 authority。SRV 或 SVCB 的 target 是中间定位结果，不能因为 DNS 选择了它，就晋升为用户原先要访问的服务身份。

这与 RFC 9460 对 SVCB/HTTPS 的安排一致：替代端点不改变 origin。也与 RFC 9525 的 reference identifier 规则一致：来自安全输入或配置的名字才是验证基准，解析途中出现的中间名字不会自动获得这种地位。

新增规则还把比较过程具体化：按 RFC 3986处理大小写与百分号编码，缺省端口补为 443，删除末尾点，依据 RFC 5890转换国际化域名；禁止通配符和 CN-ID；允许 subjectAltName 中的 DNS、IP、URI 与 RFC 4985 SRVName 形式。

这套规则保护的是一个已经存在的原始 URI。mDNS 的难点恰恰是，用户可能先浏览到服务，之后才需要构造 URI。

“来自本地链路”不是组织身份证明

RFC 6762把 mDNS 冲突处理描述为没有中央权威时，合作参与者之间的协调。IP TTL 与源地址检查能阻止链路外的响应冒充本地数据，却无法区分会场中继与同一链路上的恶意主机。RFC 还明确提醒：.local 没有全球权威，在不可信环境中仍需端到端密码保护。

RFC 6763定义 DNS-SD 怎样组织 PTR、SRV 和 TXT，并在真实性重要时建议使用 DNSSEC。它提供记录语法，不提供代表权。一个结构完全正确的服务实例，仍可能没有得到任何组织授权。

MOQT 草案当前写道，本地中继会在 .local 下发布 _moqt._udp，TXT 必须含可识别的 ALPN。然而 Security Considerations 整节仍是 TODO。它也尚未说明：从服务浏览开始的客户端，如何取得证书比较所需的原始 moqt URI；哪一项本地政策又允许广告者为该 URI 发言。

产品当然可以另加预配置、证书固定、签名发现域或明确的用户确认。这里不能反向推断为“草案存在漏洞”，只能说共同规范尚未给出这座桥。工作草案的价值本来就包括暴露未完成的部分。

证书成功之后，仍有媒体授权

MOQT Transport 第 20 版依赖 QUIC 或 WebTransport 提供传输安全，却把订阅、发布及命名空间权限交给应用或授权框架。证书可以证明对端与 reference identifier 相符，不能证明它有权代表会场、读取受保护媒体或向某个 namespace 发布。

所以完整证据至少要分成八层：收到的广告、链路来源、选中的端点、构造出的原始 URI、证书匹配、应用授权、会话建立和实际媒体结果。“发现成功”不能替这些层签一张总收据。

Lu Heng 的最小初始规范主张只把必要共同不变量放进协调层。本案中，正确的不变量是“跳转不改写权威”。现实层次要求广告、身份、权限与结果各自留证。运行代码优先则要求实际观察客户端到底验证了哪个名字、执行了哪项政策。

来源

  1. IETF Datatracker 文件记录
  2. MOQT Discovery 第 02 版
  3. 第 01 版
  4. 第 00 版
  5. 第 02 版 I-D 公告
  6. MOQT Transport 第 20 版
  7. RFC 9460：SVCB 与 HTTPS
  8. RFC 6762：Multicast DNS
  9. RFC 6763：DNS-Based Service Discovery
  10. RFC 9525：TLS 服务身份
  11. RFC 4985：SRVName
  12. RFC 3986：URI 通用语法
  13. RFC 5890：IDNA 定义
  14. Lu Heng：最小初始规范
  15. Lu Heng：现实层次
  16. Lu Heng：运行代码优先