Summary

  • Revision 01 of the MOQT discovery draft added detailed URI normalization and X.509 certificate matching on 5 September; revision 02 changed only the source-repository link. The original moqt URI authority, not an SVCB or SRV target, remains the TLS identity.
  • Local mDNS discovery is a different authority problem. A link-local _moqt._udp advertisement can identify a candidate and ALPN, but the draft's Security Considerations are still TODO and it does not yet say how a browsed relay acquires the trusted reference identity or permission to advertise.

Imagine joining a conference network and opening a live-media application. A relay appears without configuration. Its PTR record supplies a service instance, SRV supplies a host and port, and TXT says alpn=moqt. The discovery succeeded. Nothing in that sequence alone says the relay belongs to the venue, may carry this event, or is entitled to publish under the namespace the client wants.

That distinction became more visible on 5 September 2026. The individual Internet-Draft DNS and mDNS Discovery for MOQT, revision 02, was announced as a work in progress. Its Datatracker record has no IETF stream or intended-standard-level value. The draft header says Standards Track is intended and sends discussion to the Media over QUIC list; neither fact is Working Group adoption, consensus or approval.

The meaningful change landed in revision 01. Compared with revision 00, it added two sections that turn an endpoint lookup into an identity decision. Revision 02, posted later the same day, repaired the GitHub source link and did not alter those technical rules. The announcement is therefore news of a sharpened but unfinished proposal, not a deployed feature.

DNS may relocate the connection, not the authority

The draft offers three routes. SVCB records describe native-QUIC MOQT alternatives. HTTPS records can describe WebTransport alternatives. SRV provides a target and port when the richer records are unavailable. For local links, DNS-SD over mDNS advertises _moqt._udp through PTR, SRV and TXT records.

Revision 01 draws the most important line in the unicast paths. If an SVCB or SRV record points from the URI host to another machine, the client connects to the returned target and port but continues to use the original moqt URI host for SNI and certificate validation. A resolver result is an intermediate locator. It does not get promoted into the service's identity merely because it is closer to the socket.

That follows the broader RFC 9460 rule for SVCB and HTTPS: alternative endpoints do not change origin authority. It also fits RFC 9525, which distinguishes a reference identifier derived from configured or secure input from intermediate DNS names. Without an application-defined authentication process, an intermediate value is not a new reference identity.

The draft makes the comparison unusually exact. It normalizes case and percent encoding, supplies port 443 when omitted, removes a trailing dot and converts internationalized names to IDNA form under RFC 5890. It rejects wildcard matching and CN-ID. It allows relevant subjectAltName forms, including the service-name form defined by RFC 4985, while grounding URI handling in RFC 3986.

These are valuable constraints. They make it harder for a target chosen during resolution to rewrite the question the certificate must answer. But they begin with an original URI authority. That is precisely what local service browsing may not yet have.

“Came from this link” is not “may represent this service”

The mDNS section says a relay announces itself in .local and places its transport mode in TXT. A recognized ALPN tells the client which protocol label the endpoint claims to support. It does not identify the operator, authorize the advertisement or attest conformance.

RFC 6762 is explicit about the local naming model. Conflict resolution assumes cooperating participants and no central authority. The source-address and TTL checks can exclude a response that did not originate on the local link. They cannot distinguish the venue's relay from an antagonistic device already on that link. The RFC recommends cryptographic mechanisms where participants cannot all be trusted and warns that .local carries no global authority.

RFC 6763 similarly defines how DNS-SD records are named and assembled, while recommending DNSSEC where authenticity matters. The record vocabulary is not an entitlement system. A valid PTR/SRV/TXT bundle can be syntactically complete and organizationally unauthorized.

The current MOQT discovery text does not close that gap. Its Security Considerations section contains only TODO. More narrowly, it does not yet explain how a client that begins with a browsed service instance obtains the original moqt URI against which revision 01 says certificates must be checked, or which local policy decides that the advertiser may speak for that URI. An implementation can add configuration, a pinned identity, a signed discovery domain or user confirmation. The draft simply has not standardized that bridge.

This is not proof of a vulnerability. Internet-Drafts exist to expose unfinished work. The right conclusion is that local discovery should remain a candidate-generation mechanism until the application supplies the missing authority.

TLS answers one question; MOQT authorization answers another

The MOQT transport draft defines the moqt URI and relies on QUIC or WebTransport for transport security. It also keeps namespace and subscription authorization at the application or authorization-framework layer. A certificate can show that the peer is valid for the reference name. It cannot show that the peer may publish a particular track, read protected media, represent a venue or deliver the stream the user expected.

The evidence chain must therefore keep seven receipts separate: the advertisement observed; local-link provenance; the candidate endpoint selected; the reference identity constructed; the certificate result; the namespace or content authorization; and the resulting media session. Collapsing them into “relay discovered” lets the first packet borrow authority from every later step.

Heng Lu's Minimum Initial Specification supports a narrow common rule rather than a universal trust bureaucracy. The original-authority invariant is a good narrow rule. His account of reality layers explains why an advertisement, certificate and delivered stream cannot certify one another. Running-Code Primacy supplies the final test: only observed client and relay behavior can show which identity was actually checked and which policy admitted the session.

Sources

  1. IETF Datatracker record
  2. MOQT discovery revision 02
  3. MOQT discovery revision 01
  4. MOQT discovery revision 00
  5. Revision 02 I-D announcement
  6. MOQT transport revision 20
  7. RFC 9460: SVCB and HTTPS records
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: Service Identity in TLS
  11. RFC 4985: SRVName subjectAltName
  12. RFC 3986: URI generic syntax
  13. RFC 5890: IDNA definitions
  14. Heng Lu: Minimum Initial Specification
  15. Heng Lu: Reality Layers
  16. Heng Lu: Running-Code Primacy