MLS - IETF 118

Wednesday, Nov 8, 2023

Notes: Nick Sullivan

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

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

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

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

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

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

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

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

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
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
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:

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?

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

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 planning to have room state shared as GroupContextExtension to get
group agreement:

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


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

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

No update