]> Cisco

fluffy@iii.ca

Cisco

snandaku@cisco.com

Web and Internet Transport Media Over QUIC media over quic moqt uri uri resolution svcb https records service discovery srv mdns dns-sd This document defines the moqt URI scheme, URI resolution mechanisms, and discovery methods for the Media over QUIC Transport (MOQT) protocol. It specifies the URI syntax, fragment identifiers, dereferencing procedures, normalization rules, and X.509 certificate matching for moqt URIs. It also defines DNS-based resolution using SVCB and SRV records, as well as local network discovery via mDNS and DNS-SD. About This Document Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Media over QUIC Transport (MOQT) protocol identifies servers using the moqt URI scheme. Clients establish MOQT sessions over native QUIC or over WebTransport (). This document consolidates the URI definition, resolution, and discovery aspects of MOQT into a single specification. It is organized as follows:

MOQT URI Scheme ():

Defines the moqt URI syntax, fragment identifiers, and dereferencing procedures.

URI Normalization ():

Specifies canonical forms for comparison and certificate matching.

X.509 Certificate Matching ():

Rules for validating server certificates against moqt URIs.

SVCB Records ():

Unicast DNS records that carry connection parameters — including supported ALPNs — alongside address records for native QUIC endpoints. Section 2.4 of requires a mapping document for each URI scheme using SVCB; this document fulfills that requirement for moqt. For WebTransport, standard HTTPS resource record processing applies to the derived https URI.

SRV Records ():

Unicast DNS records that provide port and target information for load balancing and failover.

mDNS and DNS-SD ():

Multicast DNS and DNS Service Discovery for local network discovery without a central DNS server.

Conventions and Definitions This specification uses the terminology from , , and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

MOQT URI Scheme An MOQT server is identified using a URI with the "moqt" scheme. The "moqt" URI scheme is defined as follows, using definitions from : The authority portion MUST NOT contain an empty host portion. The moqt URI scheme supports the /.well-known/ path prefix defined in . The moqt URI scheme follows the generic URI syntax of for the authority, path-abempty, and query components, including the use of reserved characters and percent-encoding defined therein. A moqt URI can be converted to an https URI by replacing the scheme (see ), so the path-abempty and query components use the same syntax as https URIs.

Fragment Identifiers The media type for resources identified by moqt URIs is application/moqt. Fragment identifiers MAY be used with moqt URIs. The fragment is not transmitted to the server; it is processed locally by the client after establishing the MOQT session. A moqt URI fragment MUST begin with a registered fragment type identifier, followed by a colon (:), followed by a type-specific value: : ]]> Fragment type identifiers MUST consist of ASCII lowercase letters, digits, and hyphens (a-z, 0-9, -). The semantics of the value after the colon are defined by the specification that registers the fragment type.

Dereferencing a MOQT URI The default operation for dereferencing a moqt URI is to establish a MOQT session to the identified server. See for the security implications of dereferencing a moqt URI. A moqt URI can be dereferenced over two distinct transports ():

• Native QUIC, where the client opens a QUIC connection directly to the authority of the moqt URI and negotiates a moqt/moqt-N ALPN.
• WebTransport, where the moqt URI is first mapped to an https URI () and the client establishes a WebTransport session over HTTP/3 (ALPN h3) or HTTP/2 (ALPN h2) to that https origin.

The two transports use different DNS resolution and certificate validation procedures, summarized below. For the native QUIC transport, when moqt-specific SVCB records are published for the authority (), the client MAY use them to learn the server's endpoints and moqt/moqt-N ALPNs before connecting. When those records are not available, the client falls back to SRV records () or, on a local link, uses mDNS and DNS-SD (). Otherwise the client resolves the host subcomponent of the authority to one or more network addresses using DNS A and AAAA records. If the port is omitted in the URI, a default port of 443 is used. The server's X.509 certificate MUST be validated against the original moqt URI authority as described in , and the URI MUST be normalized as specified in before certificate comparison. For the WebTransport transport, the client applies standard https processing to the derived https URI: HTTPS resource records () are resolved as for any https origin, and the server's X.509 certificate matching following the same procedures as defined for native QUIC. No moqt-specific DNS records are consulted on this path.

URI Normalization For comparison purposes, the URI, or part of the URI, is put in a canonical form and then bitwise compared to the data from the X.509 certificate after putting it into canonical form. This section defines how to create the canonical form. The URI MUST be normalized using Case Normalization and Percent-Encoding Normalization as specified in Sections 6.2.2.1 and 6.2.2.2 of . The "." and ".." sequences have no special meaning in MOQT URIs and are not changed during normalization. If the port is missing, it MUST be replaced with the default port (443). If the URI reg-name ends in a ".", that MUST be removed. Internationalized Domain Names in the reg-name MUST be converted to IDNA format as defined in . When comparing hostnames, wildcard matching MUST NOT be supported and the "*" character has no special meaning.

X.509 Certificate Matching The fields referenced in this section are defined in and . The CN-ID field as defined in MUST NOT be used. Clients MUST implement dNSName, uniformResourceIdentifier and iPAddress matching. If any one of the following identifiers in the subjectAltName of the certificate matches the URI, then the certificate is valid for that URI.

• dNSName: The canonicalized dNSName from the certificate matches the host part of the authority from the canonicalized URI.
• iPAddress: The host part of the authority from the canonicalized URI, parsed as an IP address, matches the iPAddress value from the certificate.
• uniformResourceIdentifier: The canonicalized uniformResourceIdentifier MUST match the canonicalized URI with the query and fragment removed.
• SRVName: Matched as described in Section 4 of using the host part of the authority from the canonicalized URI as the name restriction and a SRVName restrictions of "_moqt".

WebTransport Certificate Validation When connecting via WebTransport, the TLS handshake terminates at an https origin derived from the moqt URI (). In this case, the client validates the server certificate against that https URI using standard Web PKI procedures; the moqt-specific matching rules above do not apply. The TLS SNI extension MUST contain the host from the derived https URI. The moqt-specific certificate matching defined in this section applies only to native QUIC connections where the client connects directly to the authority of the moqt URI. On such connections the TLS SNI extension MUST contain the host from the original moqt URI.

SVCB and SRV Indirection When a client is redirected to a different target host via SVCB or SRV, certificate matching MUST be performed against the authority from the original moqt URI, not the resolved target name. The TLS SNI extension likewise MUST contain the original authority's host. This is consistent with the requirements in and with the SRV rules in of this document. SRVName matching () applies regardless of whether the client discovered the endpoint via SRV records or SVCB records, because the _moqt service type is the same in both cases.

SVCB Records for MOQT MOQT defines SVCB records for native QUIC endpoints. For WebTransport, a moqt URI maps to an https URI (); the client resolves that https URI using HTTPS resource records following standard https processing rules ().

SVCB Record Name For a moqt URI with host H and port P, the SVCB owner name is:

• _moqt.H when P is 443 or omitted (defaulting to 443).
• _P._moqt.H when P is any other value.

Default ALPN Identifiers Unlike https (which implies h2/h3), the moqt URI scheme has no implicit default ALPN. Every ServiceMode record MUST include an explicit alpn SvcParamKey listing all supported protocols. The following ALPN identifiers are defined for MOQT:

moqt:

Connected with raw QUIC, published MOQT specification.

moqt-N (where N is a non-negative integer):

Connect with raw QUIC using draft version N (e.g., moqt-15) of the MOQT Transport draft.

Note to RFC Editor: Remove this bullet point in RFC A client MUST treat a record whose alpn contains none of its supported identifiers as unusable and proceed as if no record were present. TODO: Define ALPN identifier and record-placement rules for qmux once the qmux specification matures.

Automatically Mandatory SvcParamKeys The moqt scheme introduces no additional automatically mandatory SvcParamKeys; standard processing rules apply. Omitting alpn is equivalent to publishing a record with no supported protocols (), which clients will treat as unusable.

Relevant SvcParamKeys

alpn and no-default-alpn The alpn SvcParamKey MUST be present in every ServiceMode record (see ). The no-default-alpn SvcParamKey MUST NOT appear; with no default ALPNs defined, it has no effect and would be misleading.

port When present, port specifies the UDP port for the native QUIC endpoint. When absent, the port from the moqt URI is used, defaulting to 443.

ech ECH MAY appear in SVCB records. Clients that support ECH SHOULD use it; without it, the moqt URI authority is exposed in the TLS SNI extension ().

ipv4hint and ipv6hint MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution.

ALPN Selection A client uses the alpn SvcParamKey to determine which connection modes the server supports and connects using any ALPN identifier from the record that it supports. Selection among multiple supported ALPNs is a matter of local client policy and is out of scope for this document.

SRV Records for MOQT SRV records provide port and target for load balancing and failover but carry no ALPN or connection parameters. SRV support is retained because it is required by DNS-SD () and provides a transitional fallback for the native QUIC path in deployments where SVCB infrastructure is not yet available.

SRV Record Names For a moqt URI with host H, SRV queries are performed at:

• _moqt._udp.H

Using SRV Target and Port When SRV records are found:

• The target hostname and port from the SRV record MUST be used as the connection endpoint.
• The original moqt URI's host component MUST be used as the TLS SNI value and for certificate validation; it MUST NOT be replaced by the SRV target hostname.
• SRV targets with a port of 0 and a dot (.) target indicate that the service is not available at this name and MUST be treated as indicating no service.

Interaction with SVCB When SVCB records are available and usable for a moqt authority, clients SHOULD prefer them over SRV records and MAY skip the SRV query entirely. Operators SHOULD publish SVCB records rather than (or in addition to) SRV records for new deployments.

mDNS and DNS-SD Discovery for MOQT mDNS and DNS-SD enable MOQT discovery on local links without a central DNS server.

DNS-SD Service Names MOQT uses the following DNS-SD service types, which are also registered for SRV use ():

_moqt._udp:

Advertises MOQT endpoints (native QUIC and WebTransport over HTTP/3).

A MOQT relay on the local network announces itself by publishing PTR, SRV, and TXT records under the appropriate service type in the .local. domain, as specified in .

TXT Record Parameters The TXT record for a MOQT DNS-SD instance MUST contain the following key-value pair:

alpn:

The ALPN identifier for the transport mode advertised by this instance (e.g., moqt, moqt-15, h3).

A client MUST treat an instance whose TXT record does not contain a recognized alpn value as unusable.

Interaction with SVCB This document does not define SVCB-based service parameter delivery for MOQT DNS-SD instances; the TXT record () is the sole mechanism for conveying ALPN information in DNS-SD.

Security Considerations Dereferencing a moqt URI exposes the following information to on-path observers and intermediaries:

• The authority component is sent in the TLS SNI extension during connection establishment, exposing the target server identity to on-path observers. Encrypted Client Hello (ECH) can mitigate this exposure.
• The path-abempty and query components are visible to the relay that terminates the client's connection.

TODO: Expand this section with additional considerations.

IANA Considerations

Service Name Registration IANA is requested to register the following entry in the "Service Name and Transport Protocol Port Number Registry":

• Service Name: moqt
• Transport Protocol(s): udp
• Assignee: IETF
• Contact: moq@ietf.org
• Description: Media over QUIC Transport
• Reference: This document and
• Port Number: 443

This registration covers use of the _moqt._udp service label in SRV records () and DNS-SD ().

URI Scheme Registrations This document requests the registration of the following URI schemes in the "Uniform Resource Identifier (URI) Schemes" registry, per :

"moqt" URI Scheme Registration Scheme name: moqt Status: Permanent Applications/protocols that use this scheme name: Media over QUIC Transport (MOQT) over native QUIC or WebTransport, as defined in this document. Contact: IETF MoQ Working Group (moq@ietf.org) Change controller: IETF References: This document

ALPN Registration TODO

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Informative References Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). Meta Apple Inc. Google WebTransport over HTTP/3 is a binding of the WebTransport protocol framework [OVERVIEW] to HTTP/3 [HTTP3]. It provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. WebTransport enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport.

Acknowledgments TODO: Acknowledgments to be added.