jennings-moq-e2ee-mls-00.txt

Internet DRAFT - draft-jennings-moq-e2ee-mls

draft-jennings-moq-e2ee-mls

Last Version:	draft-jennings-moq-e2ee-mls-00.txt	Tracker Entry
Date:	`04-Mar-2024`
Disposition:	current

MOQ C. Jennings
Internet-Draft R. L. Barnes
Intended status: Informational S. Nandakumar
Expires: 5 September 2024 Cisco
4 March 2024

Secure Group Key Agreement with MLS over MoQ
draft-jennings-moq-e2ee-mls-00

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 5 September 2024.

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. TrackNamespace Subscription
4.2.1. SUBSCRIBE_NAMESPACE
4.2.2. SUBSCRIBE_NAMESPACE_RESPONSE
4.2.3. NAMESPACE_INFO
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.2. Creating/Joining a MLS Group
6.3. Updating Group State
6.3.1. Processing MLS Welcome Message
6.3.2. Processing MLS Commit Messages
7. Epoch Counter Service
7.1. Lock API
7.2. Increment 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.

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 downstream
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. TrackNamespace Subscription

In order to realize the MLS key exchange over MOQ, this specification
proposes MOQT endpoints and Relays to be able to subscribe to
TrackNamespace. A sketch of the proposal is here but this would be
moved out of this draft.

Following additions is proposed to the core MOQT protocol.

4.2.1. SUBSCRIBE_NAMESPACE

A subscriber sends SUBSCRIBE_NAMESPACE to express its interest in all
the tracks that will eventually be produced under the requested
namespace.

SUBSCRIBE_NAMESPACE
{
Track Namespace (b),
Subscribe Namespace ID (i)
}

4.2.2. SUBSCRIBE_NAMESPACE_RESPONSE

Publishers sends SUBSCRIBE_NAMESPACE_RESPONSE indicating the status
of the request for subscribing to the track namespace.

SUBSCRIBE_NAMESPACE_RESPONSE
{
Subscribe Namespace ID (i),
Status Code (i),
[Reason Phrase (b)]
}

4.2.3. NAMESPACE_INFO

Publisher sends NAMESPACE_INFO message whenever it is ready to
publish on new track under a track namespace Section 4.2.1 message.
The NAMESPACE_INFO message is a implicit subscription to the track,
unless it is explicitly unsubscribed by the subscriber by sending
UNSUBSCRIBE message. This message provides necessary mapping between
Track Alias, Subscribe Id to the namespace requested in the SUBSCRIBE
NAMESPACE message.

NAMESPACE_INFO
{
Track Alias (i),
Subscribe ID (i),
Mapped Track Namespace (b),
Mapped Track Name (b),
Mapped Request Id (i)
}

Section 6.1 provides one of the applications of namespace
subscription for MLS KeyPackage distribution.

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.

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.

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.

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 via concepts from 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 instance. As part of bootstrapping a MLS
Session, participating MOQT endpoints needs to perform the following
2 actions:

1. Subscribe to receive published MLS KeyPackages over MOQT Track
for an MLS group.

2. Publishing MLS KeyPackages over a MOQT Track.

To enable the above, following MOQT track definition is specified:

The TrackNamespace, termed "KeyPackage Namespace" is made up of 2
parts as shown below:

KeyPackage Namespace := <mls-group-name> | "keypackages"

Note: The MLS group name chosen should be unique within a MOQ relay
network.

All the members subscribe to the "KeyPackage Namespace" to receive
KeyPackages published over sender specific "KeyPackage Track"s as
shown below, where the Trackname identifies the sender of the the
KeyPackage.

KeyPackage Track
Tracknamespace := KeyPackage Namespace
Trackname := SenderId

The SenderId value chosen MUST be unique within the MOQ application.
The RECOMMENDED way to ensure uniques would be to use certificate
fingerprint of the sender's public key.

There is one MOQT Group within the KeyPackage Track and objects
within that group identify different updates to the KeyPackage from a
given publisher. KeyPackage published at Object ID of '0' is used to
initiate joining a MLS group.

Below figure depicts a sample call flow on how the MOQT Namespace
subscribe is used to enable 2 participants (joiner1 and joiner2) to
publish their KeyPackages and have the member is able to process both
of them

┌───────┐ ┌─────┐ ┌───────┐┌──────┐
│Joiner1│ │Relay│ │Joiner2││Member│
└───┬───┘ └──┬──┘ └───┬───┘└──┬───┘
│ │ │ │
│ Announce(mls-grp1|keypackages) │ │ │
│─────────────────────────────────────────────>│ │ │
│ │ │ │
│ │ Announce(mls-grp1|keypackages) │ │
│ │<─────────────────────────────────────────────│ │
│ │ │ │
│ │ Subscribe_Namespace(mls-grp1|keypackages) │
│ │<─────────────────────────────────────────────────────│
│ │ │ │
│ Subscribe_Namespace(mls-grp1|keypackages) │ │ │
│<─────────────────────────────────────────────│ │ │
│ │ │ │
│ │ Subscribe_Namespace(mls-grp1|keypackages) │ │
│ │─────────────────────────────────────────────>│ │
│ │ │ │
│Namespace_Info(namespace=mls-grp1|keypackages,│ │ │
│name=joiner1,alias=j1) │ │ │
│─────────────────────────────────────────────>│ │ │
│ │ │ │
│ │ Namespace_Info(namespace=mls-grp1|keypackages, │
│ │ name=joiner1,alias=j1) │ │
│ │─────────────────────────────────────────────────────>│
│ │ │ │
│ │Namespace_Info(namespace=mls-grp1|keypackages,│ │
│ │name=joiner2,alias=j2) │ │
│ │<─────────────────────────────────────────────│ │
│ │ │ │
│ │ Namespace_Info(namespace=mls-grp1|keypackages, │
│ │ name=joiner2,alias=j2) │ │
│ │─────────────────────────────────────────────────────>│
│ │ │ │
│ Object(alias=j1,.., payload=KeyPackage) │ │ │
│─────────────────────────────────────────────>│ │ │
│ │ │ │
│ │ Object(alias=j1,.., payload=KeyPackage)│ │
│ │─────────────────────────────────────────────────────>│
│ │ │ │
│ │ Object(alias=j2,.., payload=KeyPackage) │ │
│ │<─────────────────────────────────────────────│ │
│ │ │ │
│ │ Object(alias=j2,.., payload=KeyPackage)│ │
│ │─────────────────────────────────────────────────────>│
┌───┴───┐ ┌──┴──┐ ┌───┴───┐┌──┴───┐
│Joiner1│ │Relay│ │Joiner2││Member│
└───────┘ └─────┘ └───────┘└──────┘

6.2. Creating/Joining a MLS Group

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.

In order to realize the above functionalities and ensure the critical
invariants Section 3.1, a centralized "Epoch Counter Service" (see
epoch-svc) is required to address/resolve contention issues when
multiple participants carryout the create/join procedures.

Participants intending to join/create a MLS grooup, try to acquire
lock from the counter service. The request identifies the MLS Group
identified by its GroupId and epoch '0' as the counter to obtain the
lock. The response can be one of the following:

* Ok: A response of OK 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 (epoch 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 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.

The process of updating the group state is described below:

1. Acquire lock for the current epoch from the counter service.

2.a If the lock was successfully acquired and member is attempting to
add a new member, process the MLS KeyPackage(s) available over per
joiner's KeyPackage track, 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.1) and Publish MLS Commit
message to all the participants (see Section 6.3.2).

2.b 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.2).

1. If the response was "Locked", following the procedures for
retrying as defined in (locked).

2. 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.1. 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 Namespace := <mls-group-name> | "welcome"

Note: The MLS group name chosen should be unique within a MOQ relay
network.

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 Track
Tracknamespace := Welcome Namespace
Trackname := RecipientId

The RecipientId value chosen MUST be unique within the MOQ
application. The RECOMMENDED way to ensure uniques would be to use
certificate fingerprint of the recipients's public key. The group
member publishing the MLS Welcome message can obtain the RecipientId
while processing the KeyPackage of the member being added.

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.2. 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 Track
Tracknamespace := <mls-group-name>
Trackname := commits

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. Epoch 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, 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.

GET /lock/<Counter ID>?val=<counter>

Returns "Ok" if lock acquisition succeeded, a "Confict" response when
lock is already held with a retry_later time for retrying the lock
acquisition or a "CounterError" with the current value of the counter
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.

POST /increment/<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-03, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-03>.

[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

Richard L. Barnes
Cisco
Email: rlb@ipv.sx

Suhas Nandakumar
Cisco
Email: snandaku@cisco.com