MoQ End-to-End Encryption Profile

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. Introduction

MoQ relays forward named tracks of groups and frames ([moql], [moqt]) 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 [secure] 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.¶

3. Relationship to Other Formats

[secure] 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 (Section 6), 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 ([moql] 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 ([moql] 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 [sframe] is the cryptographic ancestor of [secure]. 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.¶

4. 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.¶

5. Credential

The application supplies an immutable credential:¶

Credential {
  context (b)
  kid (u64)
  secret (32)
}

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.¶

6. 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 ([RFC9562]): 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 Section 8, 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.¶

7. 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 Section 11.¶

8. Key Derivation

Keys and physical names are derived with HKDF-SHA-256 [RFC5869]. Let salt be the ASCII bytes of "moq-e2ee-00".¶

prk = HKDF-Extract(salt, secret)

Opaque broadcast path material is 16 bytes:¶

path_info = "moq-e2ee-00 path"
            || bytes(context)
            || u64(kid)
            || bytes(semantic_broadcast)
opaque    = HKDF-Expand(prk, path_info, 16)

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 ([RFC4648] 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:¶

name_info = "moq-e2ee-00 name"
            || bytes(context)
            || bytes(epoch)
            || u64(kid)
            || bytes(semantic_name)
physical  = HKDF-Expand(prk, name_info, 16)

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 ([RFC4648] 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:¶

key_info = "moq-e2ee-00 key"
           || bytes(context)
           || bytes(epoch)
           || u64(kid)
           || bytes(physical_name)
           || domain
key      = HKDF-Expand(prk, key_info, 16)

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.¶

9. Object Identity

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

nonce = u64(group) || u32(frame)

10. 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 [RFC5116] 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.¶

11. 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 [aeadlimits]. 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.¶

12. 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 Section 11, 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.¶

13. 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.¶

14. 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.¶

15. IANA Considerations

This document requests no registrations.¶

16. References

Changelog

Acknowledgments

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

Author's Address