# MLS - IETF 118   {#mls---ietf-118}

Wednesday, Nov 8, 2023

Notes: Nick Sullivan

# WG Recharter - Chairs 20min   {#wg-recharter---chairs-20min}

Feedback from AD: the charter should be updated to reflect the fact that
we published a document

# Working Group I-Ds - 35min   {#working-group-i-ds---35min}

Richard Barnes: we should just copy what was done in TLS  
Eric Rescorla: we shouldn't do this, but we should recharter for
individual extensions  
DKG: we should put a list of criteria for extensions that are worthwhile

Jonathan Hoyland: We should also state that we are doing a security
analysis  
Barnes: Agree with EKR and DKG, we should use the current set of
proposed extensions as a basis for constructing the text

# MLS Architecture - Benjamin Beurdouche - 5m   {#mls-architecture---benjamin-beurdouche---5m}

Close to finished - closed several PRs  
EKR: I found a few recommendations that are more optimistic than
reality. For example, the HSM storage recommendation.  
Issue 210 - we should harmonize mimi and MLS with respect to encrypted
group operations

Benjamin: Maybe we should attenuate some of the points as
recommendations.

EKR: Github issues are up, open to the crowd

EKR: Half of the 22 changes from IESG are editorial

# MLS Extensions - Rapheal Robert+Konrad Kohbruk - 30m   {#mls-extensions---rapheal-robertkonrad-kohbruk---30m}

This is a continuation of the extensions document presented at IETF 117.
Recap of changes:

*   last resort KeyPackage extension  
    recap: key that is not deleted immediately

*   SelfRemove proposal   
    addresses problem of self-commit of leaving the group by making this
    an external commit

*   Safe Extension threat model  
    Extensions risk breaking security guarantees of other extensions,
    for example if they're not aware. Implementers need to understand
    where the boundaries are.

Konrad Kohbruk: can use public key material, export secrets, inject
PSKs. Extension ID for domain separation. Next step: access control on
group context.

Sean Turner: this is essentially an IANA-gated process  
EKR: should I think of this as a TLS exporter label?  
Konrad: Yes, with the extension id as the literal separator

DKJ: Can encrypt and validate, but not encrypt and sign?  
Konrad: Slide should be updated to include secret key material for
signing

Hoyland: Is there something special we need to think about with respect
to when the extension is used?  
Robert: It needs to be advertised and agreed upon in a negotiation.
Non-safe extension need more scrutiny.

Sean: There will be three sections for the IANA?  
EKR: don't use special spaces?  
Sean: To get a codepoint, you need to come to the group. This needs to
be in the extensions document.

Rohan Mahy: In the draft but not on the slides, there are three
different variations on styles  
Konrad: In extension document (not safe API), you have to register your
extension, but not also have to register your extension proposal, just
reuse the id.

Steffen Fries: ??  
Robert: Not the secrets exporter for HPKE

Benjamin: There are a set of extensions that will support in native APIs
and some that will be able to only implement in software.  
Robert: Rather than registering extensions + proposals, you register the
idea of a safe extension and then reuse the idea. Which should make it
easier to be consistent across browsers.

Robert: Needs a security analysis.

Sean: Are mimi extensions coming to MLS or vice versa?  
Rohan Mahy: Will address

## KeyPackage Context Extension for MLS - Rohan Mahy - 25m   {#keypackage-context-extension-for-mls---rohan-mahy---25m}

Open issue: Self-remove cannot ensure removing oneself is atomic.

*   option 1: remove others, then self-remove
*   option 2: send remove other and self-remove at same time, home  
    Solutions:
*   option a: add a list of leaf indices (that correspond to the same
    user)
*   option b: change the behavior of External Commit to commit valid
    remove proposals, but this violates spec and safe extensions

Konrad: This is a problem we should address. Option A is troublesome
because it brings with it the idea of a user group. Option b is
preferred.  
Raphael: not against B, but it opens up problems. From Alice's
perspective it could be one-shot  
Rohan: Will write comments about stapling option

Hoyland: Is this mooted by user trees?  
Mahy: We're far away from user trees (1 year?)

EKR: In the application, what we want is others to throw you out  
Mahy: What you want is that if someone sees you, they should throw you
out  
EKR: Two generals problem. From the perspetive I want: when I'm out I
don't want the application to get new messages  
Mahy: You can ignore post-exit messages  
EKR: Want the DS not to forward post-exit messages  
Mahy: This is for other members  
EKR: Evicted from the group and showing up on the roster is incoherent,
not necessarily represented by the   
Mahy: more appropriate for MIMI

DKG: Not atopmic, so some users may have the extra users: paying the
cost of ghost users. User trees is the solution?  
Mahy: Do we want to do something in the meantime

draft-mahy-mls-kp-context: proposed extension that restricts a
keypackage to a specific context. Ex:

*   only to a specific group
*   only for a specific user key, idenity, domain, pubkey, maybe even
    "room"

Kohbruk: Explain where it's useful  
Mahy: Won't accidentally be added to a specific room (spammy bitcoin
group for example)

Ryo: are other groups that don't support the extension see this key
package, will they fail  
Mahy: depends on the application making this a required capability of
the keypackages that can be used

Barnes: what's the enforcement mechanism? Do members reject for a
non-matching pubkey in the KeyPackage for example?  
Mahy: a commit arrives and violates the policy, what should people do?
Accept the commit or blow up the group?  
Barnes:

Robert: MLS allows you to be added to a group with just a KeyPackage,
which is different from other groups. It would be useful to have this as
a spam enforcement mechanism. Having a flag for groups vs. 1v1 would be
useful.

Kohbruk: If you put a keypackage with this extension in a group that
doesn't support the extension, it won't be rejected by the users since
they don't understand the extension.

Britta Hale: Lots of metadata leaked, eg which groups the user is
expected to be part of. Warning sign needed.

## MIMI extensions   {#mimi-extensions}

MIMI planning to have room state shared as GroupContextExtension to get
group agreement:

*   Room policy document: eg admins can add and remove
*   Participation list:

Sean Turner: Are we going to be forced to recharter every time?  
Barnes: Delegate to the MIMI chairs for this subset

## PQ KEM   {#pq-kem}

NIST announced ML-KEM: believed to be PQ safe based on Kyber

Beurdouche: This is a cipher not an extension. Should we start thinking
about signing?  
Rohan: before it affects the protocol, it affects the credentials

Joël Alwen: CFRG is working on Kyber, is there a conflict?  
Barnes: CFRG is interim, should converge

Hale: Shouldn't hold up draft on the different PQ outcomes around
signatures

John Gray: LAMPS is working on composite hybrid agreements

Dierdre Connelly: new NIST example is not key-commiting or plaintext
commiting. Does this matter in MLS? Maybe no because of HPKE. Make sure
the proofs con

Beurdouche: The risk is DoS/group fragmentation if the key is not
committed to(?)

## Guardianship for MLS   {#guardianship-for-mls}

No update