MOQ C. Jennings
Internet-Draft S. Nandakumar
Intended status: Informational R. L. Barnes
Expires: 4 September 2025 Cisco
3 March 2025
Secure Group Key Agreement with MLS over MoQ
draft-jennings-moq-e2ee-mls-02
Abstract
This specification defines a mechanism to use Message Layer Security
(MLS) to provide end-to-end group key agreement for Media over QUIC
(MOQ) applications. Almost all communications are done via the MOQ
transport. MLS requires a small degree of synchronization, which is
provided by a simple counter service.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://suhashere.github.io/moq-e2ee-mls. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
jennings-moq-e2ee-mls/.
Discussion of this document takes place on the Media over QUIC
Working Group mailing list (mailto:moq@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
Source for this draft and an issue tracker can be found at
https://github.com/suhasHere/moq-e2ee-mls.
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 4 September 2025.
Copyright Notice
Copyright (c) 2025 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. Introduction
2. Conventions and Definitions
3. MLS Overview
3.1. Critical Invariants
4. MOQ Overview
4.1. Simple Callflow
4.2. Proposed changes to MOQT Protocol
4.2.1. Announce Full Track Name
5. MLS and MOQ
5.1. High-level Design
5.1.1. KeyPackage Distribution
5.1.2. Welcoming New Member
5.1.3. Updating MLS Group State
6. MLS Group Key Exchange over MOQT
6.1. Bootstrapping MLS Session
6.1.1. KeyPackage Distribution
6.2. Creating/Joining a MLS Group
6.2.1. MOQT Group ID Determination
6.3. Updating Group State
6.3.1. Adding a member to the MLS Group
6.3.2. Removing a member from the MLS Group
6.3.3. Processing MLS Welcome Message
6.3.4. Processing MLS Commit Messages
7. Counter Service
7.1. Lock API
7.1.1. Join API
7.1.2. Commit API
7.2. Increment API
7.2.1. Join API
7.2.2. Commit API
8. Interactions with MOQ Secure Objects
9. Security Considerations
10. IANA Considerations
11. Normative References
Acknowledgments
Authors' Addresses
1. Introduction
Media Over QUIC Transport (MOQT) is a protocol that is optimized for
the QUIC protocol, either directly or via WebTransport, for the
dissemination of delivery of low latency media. MOQT defines a
publish/subscribe media delivery layer across set of participating
relays for supporting wide range of use-cases with different
resiliency and latency (live, interactive) needs without compromising
the scalability and cost effectiveness associated with content
delivery networks. It supports sending media objects through sets of
relays nodes.
MLS is a key establishment protocol that provides efficient
asynchronous group key establishment with forward secrecy (FS) and
post-compromise security (PCS) for groups in size ranging from two to
thousands.
This document defines procedures for MOQ endpoints to engage in
secure E2EE key establishment protocol using MLS over MOQT.
More specifically, this document provides
* Design for using MOQT data model to carrying out MLS protocol
exchange
* Simple counter service interface enabling synchronization of MLS
protocol messages.
* Procedures to derive keys for MOQT object protection when using
[SecureObjects].
2. 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.
The "|" operator is is used to indicate concatenation of two strings
or bytes arrays.
3. MLS Overview
MLS protocol provides continuous group authenticated key exchange.
MLS provides several important security properties
* Group Key Exchange: All members of the group at a given time know
a secret key that is inaccessible to parties outside the group.
* Authentication of group members: Each member of the group can
authenticate the other members of the group.
* Group Agreement: The members of the group all agree on the
identities of the participants in the group.
* Forward Secrecy: There are protocol events such that if a member's
state is compromised after the event, group secrets created before
the event are safe.
* Post-compromise Security: There are protocol events such that if a
member's state is compromised before the event, the group secrets
created after the event are safe.
At a very high level, MLS protocol operates by participants sending
proposals to add/remove/update the group state and an active member
of the group commit the proposals to move the group’s cryptographic
state from one epoch to the next (see section 3.2 of [RFC9420]).
In order to setup end to end encryption of media delivered over MOQT
delivery network, producers and consumers participate in the MLS
exchange to setup group secret through which are used to derive the
keys needed for encrypting the media/data published by the members of
the MLS group.
3.1. Critical Invariants
MLS requires a linear sequence of MLS Commits in that each MLS Commit
has exactly one successor. This is achieved by using a centralized
server that hands out a token to the client that is allowed to make
the next commit (See Section 7.
4. MOQ Overview
MOQT [MoQTransport] defines a publish/subscribe based media delivery
protocol, where in endpoints, called producers, publish objects which
are delivered via participating relays to receiving endpoints, called
consumers.
Section 2 of MoQ Transport defines hierarchical object model for
application data, comprised of objects, groups and tracks.
Objects defines the basic data element, an addressable unit whose
payload is sequence of bytes. All objects belong to a group,
indicating ordering and potential dependencies. A track contains a
sequence of groups and serves as the entity against which a consumer
issues a subscription request.
Media Over QUIC Application
| time
|
TrackA +-+---------+-----+---------+--------------+---------+---->
| | Group1 | | Group2 | . . . . . . | GroupN |
| +----+----+ +----+----+ +---------+
| | |
| | |
| +----+----+ +----+----+
| | Object0 | | Object0 |
| +---------+ +---------+
| | Object1 | | Object1 |
| +---------+ +---------+
| | Object2 | | Object2 |
| +---------+ +---------+
| .
| .
| .
| +---------+
| | ObjectN |
| +---------+
|
| time
|
TrackB +-+---------+-----+---------+--------------+---------+---->
| | Group1 | | Group2 | . . .. .. .. | GroupN |
| +---+-----+ +----+----+ +----+----+
| | | |
| | | |
|+----+----+ +----+----+ +----+----+
|| Object0 | | Object0 | | Object0 |
|+---------+ +---------+ +---------+
|
v
Objects are comprised of two parts: envelope and a payload. The
envelope is never end to end encrypted and is always visible to
relays. The payload portion may be end to end encrypted, in which
case it is only visible to the producer and consumer. The
application is solely responsible for the content of the object
payload.
Tracks are identified by a combination of its TrackNamespace and
TrackName. TrackNamespace and TrackName are treated as a sequence of
binary bytes. Group and Objects are represented as variable length
integers called GroupId and ObjectId respectively.
4.1. Simple Callflow
Below is a simple callflow that shows the message exchange between,
Alice (the producer), Bob (the consumer) and Relay. The MOQT
protocol exchange starts with Alice sending MOQT Announce message
with TrackNamespace under which she is going to publish media tracks.
Then Bob issues a MOQT Subscribe message to the relay for a
FullTrackName (identified by its TrackNamespace and TrackName)
expressing his interest to receive media. Relay makes upstream
subscription to Alice since the track namespace in the subscription
matches the track namespace in the announcement from Alice. This is
followed by Alice publishing media over the requested track, which is
eventually forwarded to Bob via the Relay.
┌──────────┠┌─────┠┌────────â”
│Alice(Pub)│ │Relay│ │Bob(Sub)│
└────┬─────┘ └──┬──┘ └───┬────┘
│ │ │
│Announce(id=1,TrackNamespace)│ │
│────────────────────────────>│ │
│ │ │
│ AnnounceOk(id=1) │ │
│<────────────────────────────│ │
│ │ │
│ │Subscribe(id=1, TrackName)│
│ │<─────────────────────────│
│ │ │
│ │ SubscribeOk(id=1) │
│ │─────────────────────────>│
│ │ │
│ Subscribe(id=2, TrackName) │ │
│<────────────────────────────│ │
│ │ │
│ SubscribeOk(id=2) │ │
│────────────────────────────>│ │
│ │ │
│ Object Flow │ │
│────────────────────────────>│ │
│ │ │
│ │ Object Flow │
│ │─────────────────────────>│
│ │ │
│ │ Unsubscribe(id=1) │
│ │<─────────────────────────│
│ │ │
│ Unsubscribe(id=1) │ │
│<────────────────────────────│ │
┌────┴─────┠┌──┴──┠┌───┴────â”
│Alice(Pub)│ │Relay│ │Bob(Sub)│
└──────────┘ └─────┘ └────────┘
4.2. Proposed changes to MOQT Protocol
In order to realize the MLS key exchange over MOQ, this specification
proposes following changes to MOQ Transport. The changes are to be
discussed within the MOQ WG and will be deleted from this draft.
4.2.1. Announce Full Track Name
Announcing to Full Track Name allows authorized original publishers
to publish their objects before the subscribers express their
interest. We propose to modify the Announce message to include the
FullTrackName as shown below:
ANNOUNCE Message {
Type (i) = 0x6,
Length (i),
Track Namespace (tuple),
Track Name Length(i),
Track Name (..),
Number of Parameters (i),
Parameters (..) ...,
}
If the Track Name Length is zero, the Track Name is not included in
the Announce Message.
5. MLS and MOQ
This specification defines procedures for participants engaging in
MLS key exchange to happen over MOQT protocol, thus enabling
following 2 goals:
1. Use MOQT as delivery transport for MLS protocol messages.
2. Allow MOQT endpoints (producers/consumers) to use MLS as secure
key exchange protocol for end to end secure communications across
range of use-cases.
5.1. High-level Design
MLS [RFC9420] achieves group key agreement by participants/members
engaging in MLS protocol message exchange that allows:
* New members to express their interest to join a MLS group
* Existing members to commit a new members to a MLS group
* Existing members to commit removal of existing members from a MLS
group
The central unit of functionality in MLS is a group, where at any
given time, a group represents a secret known only to its members.
Membership to the group can change over time. Each time membership
changes (batch of joins or leaves), the shared secret is changed to
one known only by the current members. Each period of time with
stable membership/secret is an epoch.
At a high level, one can envision MLS protocol operation in the form
multiple queue abstractions to achieve the above functionality.
5.1.1. KeyPackage Distribution
All participants interested in joining a MLS group share their MLS
KeyPackage(s) with the group, thus enabling an existing member to add
new members to the MLS group. In this context, KeyPackages
distribution/processing can be modeled a "queue of KeyPackages".
Such a queue provides following properties:
* Multiple parties to write to it, when participants submit their
KeyPackages.
* Multiple parties to read/process from the queue, to process the
KeyPackage for updating the MLS group state.
+---------------------------+ +--->
Multiple ---+ | | | Multiple
Simultaneous +---> | MLS KeyPackage Queue | --+ Simultaneous
Writers +---> | | | Readers
---+ +---------------------------+ +--->
5.1.2. Welcoming New Member
Once a MLS KeyPackage is verified, an existing member can add a new
member to the MLS group and send MLS Welcome message to invite the
new member to join the group. This procedure can be abstracted via
message queues for each joiner to receive MLS Welcome messages with
the following properties:
* Accessible by multiple parties to write, but constrained so that
only one party is allowed to write for a given epoch.
* One party, the recipient of the welcome message, is be able to
read the MLS Welcome message.
+--------------------------+ +--->
---+ | | |
1 writer per +---> | MLS Welcome Queues | --+ Single
epoch +---> | (1 queue per joiner) | --+ Reader
---+ +--------------------------+ |
+--->
5.1.3. Updating MLS Group State
Members can update group's state when adding a new member, removing
an existing member or updating group's entropy at any time during a
MLS session. Group updates are performed via MLS Commit messages and
successful commits result in moving the MLS epoch further. MLS
Commit message needs to be processed by all the members to compute
the shared group secret for that epoch.
The distribution of commit messages can be modeled with a message
queue for MLS Commit messages with the following properties:
* Any member can access the commit queue for writing MLS Commit
messages, but only one member is allowed to write per epoch.
* All the members can read and process MLS Commit message from the
commit queue to update their group state.
---+ +--------------------------+ +--->
1 writer per +--->| |--+ Multiple
epoch +--->| MLS Commit Queue |--+ Simultaneous
---+ | | | Readers
+--------------------------+ +--->
6. MLS Group Key Exchange over MOQT
Section Section 5.1 provided an non-normative abstracted view (via
Queue metaphor) to illustrate various MLS operations. Subsections
below provide further normative details on realizing those
abstractions through mapping to the MOQT data model (see Section 4).
6.1. Bootstrapping MLS Session
Each participant is provisioned, out of band, the MLS Group Name for
a given MOQ application session. As part of bootstrapping a MLS
Session, participating MOQT endpoints needs to able to publish their
MLS KeyPackages and express their interest to join a MLS group. The
latter of which is discussed further in Section 6.2.
6.1.1. KeyPackage Distribution
Participants interested in joining a MLS group publish their MLS
KeyPackage by writing to the "KeyPackage" MOQT track whose details
are defined below:
KeyPackage TrackNamespace := ("moq.mls.arpa/v1"),(<mls-group-name>)
KeyPackage TrackName := ("keypackages")
KeyPackage FullTrackName := KeyPackage TrackNamespace | KeyPackage TrackName
The MLS group name chosen MUST be unique within a MOQ relay network.
There is one MOQT Group per participant, where the Group ID
represents the Sender/Participant within the MLS Group. Each
participant is identified by a SenderID value and MUST be unique
within the MOQT Session. The MOQT Object is used to carry
participant's MLS KeyPackage. A participant can update their
KeyPackage by publishing a new object with the same group.
Online members with active subscription to the "KeyPackage" track
receive KeyPackages published by the participants. Members who are
offline continue with their subscriptions to the "KeyPackage" track
when they come online and also issue FETCH request to retrieve the
missed MLS KeyPackages published since they were last online. The
Sender ID value to be used for the MOQT Group ID for FETCH request is
obtained via "Create/Join" flow as defined in Section 6.2.
Publishers of the KeyPackage SHOULD set the cache duration to take
into consideration the offline nature of the members. The cache
duration of 12 hours is RECOMMENDED.
6.1.1.1. Rationale for using Sender ID to be the MOQT Group ID
One can envision one MOQT Track per sender instead of the above
proposal for MLS KeyPackage publishing. However, the challenge with
such an approach is that it would require each subscribers to learn
about all the Sender IDs in the MOQ Session. Even though approaches
like "Subscribe_Announces" might help when all the members are
online, it doesn't help when members are offline. The current
proposal of having one MOQT Track for KeyPackage distribution address
the aforementioned drawback.
6.2. Creating/Joining a MLS Group
Participants intending to join a MLS group do so by sending "Join
Request" over a MOQT Track called "Join Track", as defined below:
Join TrackNamespace := ("moq.mls.arpa/v1"),(<mls-group-name>)
Join TrackName := ("join")
Join FullTrackName := Join TrackNamespace | Join TrackName
The MOQT Group ID is determined via the "Counter Service" (see
Section 7) as described in the Section 6.2.1. MOQT Object IDs
starting from 0 are used to carry the "JoinRequest" message as shown
below:
JOIN Message {
Type (i) = 0x1,
Sender ID (i)
}
* Sender ID: Identifier of the participant intending to join the MLS
group. This MUST match the Sender ID used for publishing the MLS
KeyPackage.
It is RECOMMENDED that Join messages be cached in the relays by
setting the max_cache_duration to atleast 30 minutes.
6.2.1. MOQT Group ID Determination
Creating or Joining an MLS group requires a way for boostraping the
group when the first member joins and a way to decide an existing
member for processing the MLS KeyPackage to add the new member.
Participants intending to join/create a MLS group try to acquire lock
from the counter service on the join endpoint Section 7.1.1. The
request identifies the MLS Group Name as the Counter ID to obtain the
lock.
The response can be one of the following:
* Ok: A response of OK on the "Join" MOQT Track implies that there
doesn't exist an MLS Group. In this scenario, the participant is
the first participant and thus creates the group unilaterally and
generates the initial secret for the group. Following which the
participant releases the acquired lock by performing the increment
operation for the obtained lock, on the counter service.
* Locked: A response of "Locked" implies a conflicting request and
the requestor has to retry acquiring the lock, after the lock
expiry timeout provided in the response.
* CounterError: A response of CounterError implies that the service
has a different value of the current counter than the one
requested (counter 0). This happens when the requested MLS Group
has already been created. In such situations, the participant
awaits for an existing member to add the joining participant and
publish the MLS Welcome message (see Section 6.3).
6.3. Updating Group State
Updating MLS group state requires Section 3.1 to be satisfied. This
means that the changes have to be done linearly and changes to the
group state MUST be performed by a single member within a MLS group
for a given epoch.
Group state in MLS can be udpated by adding a new member, removing an
existing member or updating the group's entropy.
6.3.1. Adding a member to the MLS Group
Members obtain a list of participants interested in joining a MLS
group either as part of updates to their subscriptions to the "Join"
Track and/or by issuing FETCH request to retrieve the missed MLS Join
messages based on the Latest Group ID in the Subscribe_OK message.
This supports processing join requests even when the members were
offline for a period of time.
The following process followed when adding a new member to a given
MLS Group:
1. Acquire lock for the current epoch from the counter service
(Section 7.1.2).
2. If the lock was successfully acquired retrieve the MLS
KeyPackage(s) from the cache by issuing FETCH request to the
"KeyPackage" track against the the Sender ID in the Join message.
The Sender ID maps to the start_group in the FETCH request and
end_group is set to start_group + 1. If successfully retrieved,
process the KeyPackage and generate set of MLS Welcome messages
per joiner and a single MLS Commit message for the group.
Publish individual MLS Welcome messages to the intended
recipeints on per recipient welcome track (see Section 6.3.3) and
Publish MLS Commit message to all the participants (see
Section 6.3.4).
6.3.2. Removing a member from the MLS Group
If the lock was successfully acquired and the operation is to remove
a member, update the MLS state to remove the member, generate MLS
Commit message and publish the generated MLS Commit message to all
the participants (see Section 6.3.4).
In either of the flows, If the response was "Locked", follow the
procedures for retrying. A lock response of "CounterError" implies
the member attempting to update the MLS group state is behind and
MUST await until it catches up with all the MLS Commit messages in
transit. It is important to note, this situation MAY also imply that
another member won the contention to update the group state before
this member can make the change.
6.3.3. Processing MLS Welcome Message
In order to be able to publish MLS Welcome message and process the
same over MOQT, following track naming scheme is specified.
The TrackNamespace, termed "Welcome Namespace" is divided into 2
parts as shown below:
Welcome TrackNamespace := ("moq.mls.arpa/v1"),(<mls-group-name>),(<welcome>)
MLS Welcome message is published over a track that is specific to
individual recipient. Joining participants subscribe to the "Welcome
Track" as part of MLS session bootstrapping, which has the following
structure:
Welcome Tracknamespace := Welcome TrackNamespace
Welcome Trackname := (<Paricipant ID>)
The Paricipant ID is same as the Sender ID obtained from the Join
message when processing the MLS KeyPackag. On receipt of the Welcome
message, local MLS state is updated with the received MLS Welcome
message to obtain the group secret for the current epoch.
When publishing on the "Welcome Track", there is one MOQT group per
MLS epoch and objectId 0 carries the MLS Welcome message.
6.3.4. Processing MLS Commit Messages
All the members subscribe to receive MLS Commit message and they do
so by subscribing to the "Commit Track" as shown:
Commit Tracknamespace := ("moq.mls.arpa/v1"),(<mls-group-name>)
Trackname := commit
MLS Commit message updates the existing member about group changes,
such as adds/removes and entropy updates. Publish to the "Commit
Track" happens with one MOQT group per MLS epoch and objectId 0
carries the MLS Commit message.
7. Counter Service
A counter service tracks a collection of counters with unique
identifiers. In an MLS context, the counter value is equal to the
MLS epoch when performing MLS group commit operations (see
Section 6.3) and an incrementing counter value for processing MLS
Group Join operations (see Section 6.2), and the counter identifier
is the MLS group identifier/MLS group name.
Before a counter can be incremented, it must be locked. As part of
the lock operation, the caller states what their expected next
counter value, which much match the service's expectation in order
for the caller to acquire the lock. Since the actual updates to the
counter are out of band, this ensures that the caller has the correct
current value before incrementing.
There is no explicit initialization of counters. The first call to
lock for a counter must have expected_next_value set to 0.
There is no method provided to clean up counters. A service may
clean up a counter if it has some out-of-band mechanism to find out
that the counter is no longer needed. For example, in an MLS
context, once the MLS group is no longer in use, its counter can be
discarded.
7.1. Lock API
This is a simple REST style API over HTTPS used to request lock for a
counter for a provided Counter ID.
7.1.1. Join API
Join lock API is used to acquire lock for a counter for a given
Counter ID when a participant is trying to join a MLS group. The
Counter ID MUST correspond to MLS Group Name.
GET /lock/join/<Counter ID>?val=<counter>
7.1.2. Commit API
Commit lock API is used to acquire lock for a counter for a given
Counter ID when a participant is trying to update the MLS group
state. The Counter ID MUST correspond to MLS Group Name.
GET /lock/commit/<Counter ID>?val=<counter>
Above APIs can be responded with the following responses:
* "Ok" response impliesthat lock acquisition was successfull,
"Confict" response implies that lock is already held with a
retry_later time for retrying the lock acquisition.
* "CounterError" response with the current value of the counter is
returned when the requested counter doesn't match the
expected_next_value.
7.2. Increment API
The increment HTTPS API allows the counter value stored in
expected_next_value to be incremented for the provided Counter ID.
7.2.1. Join API
The increment Join API is used to increment the counter value for a
given Counter ID when a participant has successfully acquired the
lock on performing the join operation. The Counter ID MUST
correspond to MLS Group Name.
POST /increment/join/<Counter ID>
7.2.2. Commit API
The increment commit API is used to increment the counter value for a
given Counter ID when a participant has successfully acquired the
lock on performing the commit operation. The Counter ID MUST
correspond to MLS Group Name.
POST /increment/commit/<Counter ID>
Returns "Ok" if the counter value was successfully incremented, a
"Error" responses if the provider "Counter ID" hasn't been locked
yet.
TODO: Define Error responses and codes for authorization failures.
8. Interactions with MOQ Secure Objects
MLS Key agreement generates a group shared secret, called "MLS Mater
Key", per MLS Epoch. Epochs in MLS are incremented whenever there is
changed in the group state due to an existing member commit the
changes to the group.
MLS generated shared group secret per epoch can be used to derive
track_base_key when using SecureObjects (see Section 5 ) for
protecting the objects within a MOQT track.
The procedure for the same is as defined below:
For each combination of (MLS Epoch, MLS Master Key) an 'Epoch Secret'
is derived:
Epoch Secret = HKDF.Extract("SecureObject Epoch Master Key " | MLS Epoch, MLS Master Key)
'Epoch Secret' is used to derive track_base_key per FullTrackName
(see Section 3 of [SecureObjects]):
track_base_key = HKDF.Expand("SecureObject Track Base Key " | FullTrackName, Epoch Secret)
When encrypting/decrypting objects using SecureObject, the epoch
under which the track_base_key was computed is used as KID in the
SecureObject Header. The track_base_key computed is used to derive
per object keys and nonce as defined in Section 5 of [SecureObjects].
All the objects within a given epoch are encrypted/decrypted with the
keys derived from the Epoch Secret for that epoch.
9. Security Considerations
TODO Security
10. IANA Considerations
This document has no IANA actions.
11. Normative References
[MoQTransport]
Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
I. Swett, "Media over QUIC Transport", Work in Progress,
Internet-Draft, draft-ietf-moq-transport-09, 1 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-09>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
[SecureObjects]
"Secure Objects for Media over QUIC", n.d.,
<https://suhashere.github.io/moq-secure-objects/#go.draft-
jennings-moq-secure-objects.html>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Cullen Jennings
Cisco
Email: fluffy@cisco.com
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Richard L. Barnes
Cisco
Email: rlb@ipv.sx