]>

kixelated@gmail.com

wit moq This document specifies moq-e2ee-00, a versioned profile for end-to-end encryption of MoQ application payloads. Authorized publishers and subscribers share a 32-byte broadcast secret out of band. Each publisher instance mints an epoch and publishes under an opaque broadcast path ending in it. HKDF-SHA-256 derives opaque physical track names and per-track AES-128-GCM keys from the secret and the epoch; grouped frames and datagrams use separate key domains. Media frames and datagrams carry only ciphertext plus a 16-byte tag. The profile binds object identity through derivation and the nonce, not an on-wire header. This document was generated by an AI model from the implementation at github.com/moq-dev/moq and is maintained alongside it. Submit an issue or PR if this spec sucks and you want to fix anything.

Conventions and Definitions 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.

Introduction MoQ relays forward named tracks of groups and frames (, ) without parsing application payloads. This profile encrypts those payloads and hides the semantic broadcast and track names that would otherwise describe them, so a relay cannot recover content. It reuses AES-128-GCM and the 96-bit group/frame nonce shape of where those identities map, and specifies the moq-lite and datagram bindings that draft does not cover. The profile does not distribute keys, sign senders, pad payloads, or rotate a key inside an epoch. Applications that need those properties terminate this profile and run a different one.

Relationship to Other Formats encrypts a MoQ Transport object under a per-track base key. Its nonce is a per-track salt XOR uint64_be(group) || uint32_be(object), its AAD includes publisher priority and immutable properties, and the Key ID rides in those properties. The object payload is a length-prefixed plaintext plus an optional encrypted-properties list. This profile keeps AES-128-GCM, HKDF-SHA-256, a 96-bit nonce of uint64_be(group) || uint32_be(frame), and the rule that an identity is used at most once. It differs where the models diverge: One 32-byte broadcast secret authorizes every track. Per-track keys are derived, not supplied. The Key ID is part of the out-of-band credential. No per-frame header or immutable property carries it. The salt is not derived from the key. The publisher instance's epoch is an input to every derivation and the last segment of the broadcast path (), so a restarted publisher derives new keys instead of needing a new Key ID. The nonce is the identity counter itself, not a salt XOR. The derived key is already unique per credential, epoch, physical name, and domain. The payload is ciphertext concatenated with the 16-byte tag, with no inner length prefix, encrypted properties, or padding. moq-lite frame indices are implied by position in the group ( Section "Frame"), not an on-wire object ID. This profile still uses that index as the 32-bit nonce half, because it is the only canonical end-to-end frame identity on both moq-lite and MoQ Transport. moq-lite datagrams share the group sequence namespace of the same track ( Section "Datagrams"). A grouped frame 0 and a datagram with that sequence would collide under one AES-GCM key, so datagrams use a separate key domain with frame ID zero. SFrame is the cryptographic ancestor of . This profile is not SFrame: it has no SFrame header, no CTR field on the wire, and no per-object KID. The experimental moq-secure format (https://github.com/cathode-ray-tube/moq-secure) is prior art only. Its independent counter, 17-byte per-frame header, ChaCha20-Poly1305 suite, signing lease, payload padding, and bytes-only processor are not compatibility requirements.

Profile Version This document defines profile moq-e2ee-00. The profile is named out of band alongside the credential; an application MUST refuse a credential that names any other profile. A new profile is a new document; implementations MUST NOT fall back to plaintext or to an older profile because a catalog, announcement, or peer suggested one.

Credential The application supplies an immutable credential:

context: Opaque bytes chosen by the application as the broadcast's end-to-end identity. Both ends MUST use identical bytes. The MoQ broadcast path is visible to relays and may be remounted under another prefix, so it is not this field unless the application copies it in. kid: Selects among credentials the application retains. It never changes in place; rotating the secret is a new kid. secret: Exactly 32 bytes from a cryptographically secure random generator. It MUST NOT be a password, passphrase, or other guessable input. kid MUST be in 0..=2^53-1 inclusive, the largest integer TypeScript can represent exactly. context, every epoch, and every semantic broadcast or track name MUST be at most 65535 bytes, the bytes encoding width. An implementation MUST refuse a credential outside those ranges (identity) or whose secret is not 32 bytes (invalid_secret). Applications distribute credentials over their own authenticated channel. MoQ announcements, catalogs, paths, and relay authorization MUST NOT carry the secret or authenticate it. Implementations MUST let the application retain more than one credential and select among them; they MUST NOT infer the kid from the transport.

Epoch and Broadcast Path A generation is one credential under one epoch. Every derivation and every nonce is scoped to a generation. epoch: Opaque nonempty bytes minted by the publisher instance, containing no /. Each instance of a broadcast MUST mint an epoch that no other instance under the same credential has used or will use. Two instances MUST NOT share an epoch: they would derive the same keys and collide on nonces. The RECOMMENDED epoch is the lowercase text of a UUID version 7 (): its leading 48-bit timestamp makes epochs sort by creation time and its random bits make collisions negligible. A protected broadcast is published at <opaque>/<epoch>, where <opaque> is the 22-character base64url segment derived from the credential and the application's semantic broadcast name according to , and <epoch> is the epoch text. The opaque derivation does not include the epoch, so every instance of the same semantic broadcast shares a discovery prefix. The path carries no format or protection marker; for example, the semantic name meeting.hang appears only as an input to the opaque derivation. A plaintext consumer that opens the protected broadcast fails because it cannot find the plaintext catalog it expects, not because of a path naming rule. Subscribers discover instances by the <opaque>/ prefix and select the greatest epoch when epochs are UUID version 7 text, where greatest is newest. Opaque epochs carry no creation order, so any other epoch form needs an application rule for which instance is current. A subscriber that already knows the full path takes the epoch from its last segment. The epoch and the path are not secret and are not authenticated. A relay that presents a wrong epoch causes authentication failure; a relay that withholds a newer instance denies service. Neither can cause a nonce to repeat, because only the publisher instance chooses the epoch it encrypts under. A restart or replacement of a publisher is a new instance and mints a new epoch. Transport sequence numbers therefore restart freely without any coordination between instances. Ended instances remain readable at their own path for as long as relays or archives retain them.

Canonical Encoding HKDF info fields use unique encodings, not varints. u16 / u32 / u64: unsigned big-endian integers of that width. bytes: u16(length) || data, length at most 65535. ASCII labels are the UTF-8 bytes of the quoted string, with no length prefix of their own. Integers used as group, frame, or kid identities are refused before encoding if they fail .

Key Derivation Keys and physical names are derived with HKDF-SHA-256 . Let salt be the ASCII bytes of "moq-e2ee-00".

Opaque broadcast path material is 16 bytes:

semantic_broadcast is the UTF-8 bytes of the application's semantic broadcast name. The opaque path segment is the unpadded base64url encoding of opaque ( Section 5): 22 ASCII characters. The epoch is deliberately absent from this derivation, so a subscriber can derive the prefix before discovering an instance. Physical track name material is 16 bytes:

semantic_name is the UTF-8 bytes of the application's track name (catalog.json, video, and so on). The physical track name is the unpadded base64url encoding of physical ( Section 5): 22 ASCII characters, which is a valid moq-lite track name. This function may hide any track-shaped name the application wants a relay not to read; it is not limited to media tracks. AEAD keys are 16 bytes, one per physical name and domain:

domain is a single byte: 0x00 for grouped frames, 0x01 for datagrams. physical_name here is the 22-character ASCII string, not the raw 16-byte material. A given (generation, physical_name, domain) tuple has one key. Implementations MUST derive names from semantic names, then keys from the resulting physical names. A subscriber that learns a physical name from a decrypted catalog derives its key without ever knowing the semantic name.

Object Identity A protected object is the tuple (generation, physical_name, domain, group, frame).

Grouped Frames A grouped frame uses domain = 0x00, the group's sequence as group, and the frame index within that group as frame. moq-lite numbers frames from 0 in write order (). On MoQ Transport, frame is the explicit Object ID, never its arrival ordinal. Publishers supporting both transports MUST assign contiguous Object IDs from zero so that each matches its moq-lite write-order index; relays MUST NOT renumber protected objects. An Object ID above 2^32-1 MUST be refused as identity before encryption or decryption.

Datagrams A datagram uses domain = 0x01, its 64-bit sequence as group, and frame = 0. MoQ Transport has no datagram mapping in this profile; shared vectors cover grouped tracks on both transports and datagrams on moq-lite only.

Nonce The 96-bit AES-GCM nonce is:

AES-GCM's internal block counter is not frame. Implementations MUST call a standard AEAD API with this nonce and an empty AAD. The empty AAD is deliberate: profile version, context, epoch, kid, physical name, and domain are bound by HKDF; group and frame are bound by the nonce. Rewritten timestamps and mutable routing properties are not authenticated.

Payload Protection Let Nt = 16. AES-128-GCM encrypts the application bytes with key, nonce, and empty AAD. The bytes placed in the MoQ frame or datagram payload are ciphertext concatenated with the 16-byte tag, in the convention. There is no inner header. Within a generation a publisher MUST allocate group and datagram sequences monotonically and frame indices in write order, so an identity is encrypted at most once. Encrypting at an identity the same instance already used is reuse and MUST be refused. Relays and caches forward ciphertext unchanged, so replay from a cache never re-encrypts.

Plaintext Ceiling Protected payload length is plaintext length plus Nt. A publisher MUST refuse plaintext that would make the protected payload exceed the transport payload limit for that object (oversize), before it touches the network. The interoperable grouped-frame payload cap matching current moq-net implementations is 32 MiB, so grouped plaintext MUST be at most 32 MiB - 16 bytes. moq-lite datagram bodies MUST remain at most 1200 bytes including Subscribe ID, Group Sequence, and Timestamp ( Section "Datagrams"). Those three varints are at most 24 bytes, so datagram plaintext MUST be at most 1200 - 24 - 16 = 1160 bytes; a publisher cannot observe the Subscribe ID each hop will encode and MUST NOT budget for a smaller header.

Catalogs A catalog is a track like any other: published under the physical name derived from its semantic name, with each snapshot or delta protected at its own group and frame identity. Hang catalog.json and catalog.json.z and MSF's catalog are semantic names; authorized clients derive those physical names from the generation, then learn the remaining opaque names from the decrypted catalog. A Hang rendition-map key in that catalog is the physical name of the track. If a representation is compressed, compression is applied to the catalog bytes before AEAD and reversed after decryption. Encrypting then compressing is forbidden: ciphertext does not compress, and the .z sibling would leak the uncompressed size ratio.

Bounds Implementations MUST refuse non-integer identities (including NaN and infinities) and identities outside these bounds before encoding or AEAD: group (grouped sequence or datagram sequence) and kid: 0..=2^53-1. Above that is identity. frame: 0..=2^32-1. 2^32 and above is identity. AEAD operations with one key: at most 2^24 invocations and at most 2^36 plaintext bytes (2^32 16-byte blocks). Exceeding either is exhausted. 2^53-1 is Number.MAX_SAFE_INTEGER. It is the strictest exact integer bound across current TypeScript and Rust implementations. The 32-bit frame width is the nonce field. The 2^24 invocation cap is the interoperable AES-GCM record limit from . GCM authenticity also depends on total processed blocks, so 2^24 frames at the 32 MiB transport ceiling would be about 2^45 blocks; the 2^36-byte cap is the matching total-block bound. Small records hit the invocation cap first; large records hit the byte cap first. A receiver counts failed opens too, since each is an AEAD invocation under that key.

Failure Behavior E2EE is an explicit per-broadcast mode. There is no plaintext fallback. Typed failures: invalid_secret: secret is not 32 bytes. identity: an integer is outside , a bytes field exceeds 65535, an epoch is empty or contains /, a physical name is not 22 base64url characters, or domain is not 0x00/0x01. exhausted: the next AEAD operation would exceed 2^24 uses of that key or 2^36 plaintext bytes under that key. reuse: encrypting at an identity this instance already used. oversize: plaintext plus tag exceeds the transport payload limit, or a ciphertext is shorter than Nt or larger than that limit. authentication: AEAD open fails. Relocation across context, epoch, kid, physical name, domain, group, or frame is this failure. duplicate: a receiver has already opened this datagram sequence inside its retained window. Operational, not a cryptographic event. Authentication failure on a grouped track MUST end that track with authentication. Authentication failure on a datagram MUST drop that datagram and emit authentication; the track continues. Grouped frames need no duplicate window: a transport delivers each frame of a group once, in order, at its index. Receivers SHOULD suppress datagram sequences they still retain; the window MUST be bounded, and 1024 sequences below the greatest opened is RECOMMENDED. The AEAD identity and epoch rules are the security boundary; a relay may still delay, reorder, suppress, or replay ciphertext outside a receiver's window. A late subscriber MAY start at any group the publisher still holds. Gaps are not errors. A receiver MUST NOT require group 0 or any prior identity before opening a later authentic object.

Test Vectors Known-answer and negative vectors live in moq-e2ee-00.json beside this draft. Hex strings are octet sequences. The JSON is authoritative for primitive interop; an implementation of this profile MUST pass every vector. Each negative row specifies an operation, its inputs, and its expected typed error. Non-finite frame inputs use the strings NaN, Infinity, and -Infinity; group inputs in identity tests are decimal strings. Implementations whose types cannot represent an invalid input MUST reject it at their input boundary. The file covers opaque path derivation, key derivation, physical naming, grouped frames, a datagram at the fixed budget, the same identity under two epochs, relocation across every identity dimension, tag failure, malformed physical names, identity bounds, and oversize plaintext. The shared verifier is stateless. It does not verify reuse, exhausted, duplicate, or failure propagation. Each language core MUST test those lifecycle requirements, including monotonic allocation, per-key invocation and plaintext-byte accounting, bounded datagram suppression, and that a new instance under a new epoch authenticates while the old epoch does not. Passing the primitive vectors alone is not profile conformance.

Security Considerations Relays, caches, recorders, and control planes are untrusted for content. Authorized endpoints that hold the broadcast secret are trusted. Sender authenticity against another endpoint that also holds the secret is not a goal of moq-e2ee-00. A relay can still observe the outer broadcast path including the opaque segment and epoch, opaque physical names, group and frame structure, timestamps, sizes, and traffic patterns. Padding and metadata-flow confidentiality are out of scope. The opaque segment hides the application's semantic broadcast name from a relay only while the application does not publish or otherwise expose the same name in plaintext. The epoch remains visible to every relay on the path. Nonce reuse under one key is catastrophic for AES-GCM. The profile prevents it by deriving every key from an epoch that only one publisher instance ever uses, allocating identities monotonically within that instance, separating datagram and grouped domains, and capping invocations and plaintext bytes per key. No state survives an instance: nothing needs to be persisted across restarts to stay safe. Empty AAD does not weaken the binding: every immutable end-to-end field is in the HKDF info or the nonce. Timestamps are excluded because relays rewrite them; a relay can therefore shift or reorder authentic objects in time within a receiver's tolerance. The opaque path segment is a deterministic function of the secret and semantic broadcast name; physical track names are deterministic functions of the secret and epoch. An attacker without the secret cannot predict them; an attacker with the secret can derive every name, which is intended.

IANA Considerations This document requests no registrations.

moq-lite is designed to fanout live content 1->N across the internet. It leverages QUIC to prioritize important content, avoiding head-of- line blocking while respecting encoding dependencies. While primarily designed for media, the transport is payload agnostic and can be proxied by relays/CDNs without knowledge of codecs, containers, or encryption keys. 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 describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. 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. 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 document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. Cisco Cisco Cisco This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers that share a symmetric key with end subscribers, to ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Additionally it allows MoQ parameters to be protected so the publisher can select if they are readable and/or modifiable by relays. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Hang is a real-time conferencing protocol built on top of moq-lite. A room consists of multiple participants who publish media tracks. All updates are live, such as a change in participants or media tracks.

Changelog

draft-lcurley-moq-e2ee-00 Initial moq-e2ee-00 profile: out-of-band credential, opaque broadcast path with a publisher-minted epoch as its last segment, HKDF physical names and keys, AES-128-GCM payloads, identity bounds, typed failures, and shared primitive vectors.

Acknowledgments This document was drafted with the assistance of Grok, an AI assistant by xAI.