| Internet-Draft | moq-mls | March 2024 |
| Jennings, et al. | Expires 4 September 2024 | [Page] |
TODO Abstract¶
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.¶
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 2024.¶
Copyright (c) 2024 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.¶
TODO Introduction¶
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.¶
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.¶
In order to setup end to end encryption of media delivered over MOQT delivery network, producders and consumers participate in the MLS exchange to setup group secret through which are used to derived the keys needed for encrypting the media/data published by the members of the MLS group.¶
Below figure captures a typical setup for clients to participate in the MLS protocol, with Delivery Service (DS) acting as the rendezvous point. In the example setting, participants A, B and C involve in protocol exchange to setup end to end encrypted session keyed via MLS.¶
TODO: Add a simple call-flow here¶
Unit of MLS functionality 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¶
As part of bootstrapping a MLS Session, each MOQT endpoint needs to perform following 2 actions:¶
Adding or joining an MLS group requires one of the following:¶
A way for boostrapping the group when the first member joins.¶
A way to choose an existing member to add a new member.¶
In order to realize the above functionalities and ensure the criticial invariants, a centralized lock service is required to help resolve contention.¶
Participants intending to join try to acquire lock to create/join the group. If the lock can be successfully acquired and the response indicates "Create", the participant is the first participant and he creates the group unilaterally and generate the initial secret. Then the pariticipant release the "crate_or_join" lock.¶
Alternately, if the repsonse indicate "Join", then the participant awaits for an e existing member to process the request to join the group.¶
When an existing member receives KeyPackage, the process of adding the new member is as follows:¶
Acquire lock to commit to the group for a given epoch¶
If lock acquired sucessfully, process the keyPackage for duplicates/error, create MLS Welcome and Commit messages, publish them to the "Welcome" and "Commit" tracks for the MLS Group and the epoch. See Section 5 for further details on the tracks.¶
If lock cannot be acquired due to conflict for a given epoch, retry after a confgured timeout. One of the 2 things might happen:¶
Another member was able to successfuly perform group update for the current epoch, in which case it is recommended for the member to process MLS messages before retrying the operation again for the same epoch to ensure the group updates are already what the member wants.¶
Another member updated the group state with commits that are different from the member attempting to obtain the lock. In such a scenario, the member needs to wait to process the commits in transit and retry step 1 for the next right epoch in the sequence¶
Participants await MLS Welcome message after publishing their Keypackage to join the group. They do so by subscribing to the "Welcome" track. On receipt of the Welcome message, local MLS state is updated with the recevied Welcome message to obtain the group secret for the current epoch. If the participant is already a member of the group, the Welcome message is dropped/ignored.¶
TODO: Add details¶
All the participants subscribe to "Commit" track for a given MLS group. This allows them to process MLS commit messages being published under the following group update operations¶
TODO: SHOULD we even support other updates ?¶
For all the various tracks:¶
The TrackNamespace is scoped to the combination of MLS Group and MLS operation. The MLS group name chosen should be unique within a MOQ relay network.¶
TrackNamespace := <mls-group-name> | <mls-operation>¶
TrackName identifies the sender performing the operation. The value chosen for sender MUST be unique within a MOQ application.¶
TODO: add notes on ways to choose the sender¶
Subscribe happens on the track namespce¶
TrackNamespace := mls-group | "keypackage" and¶
and publishes happens on the¶
FullTrackName := mls-group | "keypackage" | sender-id¶
There is one MOQT group and objects within that group identify different updates of the KeyPackage with objectId of 0 being sent at the time of joining a MLS group¶
TODO: Define API for the lock service¶
TODO: Describe epoch secret -> track_base_key¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶