MLS IETF 124 November 3 2024

Chair stuff

Agenda bash:

• Review WG IDs
• Non-WG IDs
• Many Rohan drafts

mls-extensions (Raphael Robert)

• Since last time, some PRs were merged

• Pending issues

• Sean: When can we get this closed so the doc can move along?

• Raphael: Next few weeks.

• Sean: Do we have implementation experience?

• Raphael: yeah, we need more. Please contact Raphael if you are
  implementhing this draft.

MLS cipher suites using ML-KEM (Rohan Mahy)

• Align KEM names with HPKE PQ doc
• Debating format requirements for ciphersuites names
• Minimum SHA-384 and AES256 per NIST guidelines
• Contact Richard Barnes and Rohan if you want other sizes!

• There are pure PQ variants, please speak up if you do/don't want

• Mike Ounsworth: what does type column mean, slide 2?

• Rohan: PQ = post quantum. T = traditional, hybrid = hybrid,
  KEM/Signature

• Britta Hale: Would be nice to have ML-DSA-87 w/ SHA-384 + ML-KEM
  1024

• Richard Barnes: Let's adapt the existing one instead of introducing
  new ones. Do we want both 192 and 256 level ciphersuites?

• Britta: yes I want both.

• Richard Barnes: Docs are moving through HPKE WG. The bits are set,
  let's WGLC this stuff.

• Sean: So we're going to add a new ciphersuite, then last call.

Decentralized MLS (Konrad Kohbrok)

• Have tried to situate this draft relative to another distributed MLS
  notion. The two are complementary.
• This work: stronger forward secrecy if you allow forks in group
  state
• Good for large groups where forks are unlikely.
• Useful in federated environments
• A security proof exists since this is from an academic paper
• Next up: simplify the draft and do some efficiency improvements

Distributed MLS (Mark Xue)

• Allow group participants to evolve crypto state through PCS state
• Local state becomes an MLS group
• 2 implementations underway

• Authors think it's ready for WG adoption

• Brendan McMillion: There is a consensus protocol to agree on group
  membership. Why not use that to order commits?

• Mark: this is designed to be downstream of an application level
  notion of group membership.

• Richard Barnes: This is a good contribution. There's ways to tackle
  dynamic group membership.

• Richard: there's a single problem (no DS), but we have two docs
  (this + Decentralized). Can we adopt a merged document?
• Rohan Mahy: should we pick one of the two?

• Richard: no, these two things are different and both valuable.

• Britta Hale: Decentralized is for federation, distributed is for
  mesh networks. Different problems with different solutions. The mesh
  solution is more expensive than what's needed for federated case.
  It's worth keeping both solutions.

• Nick Sullivan: how do you contrast these two approaches?

• Mark: Distinction is how much knowledge of forked state the app has
  to consider. Distributed MLS is about lazily recovering a state
  agreed to be correct.

• Britta: Distributed version is about recovering from a disconnected
  graph. But not forks. Decentralized case is all about resolving
  forks, much more pertinent in a federated environment. For these
  reasons, merging doesn't make sense.

• Raphael Robert: We can think of TIME ITSELF as being the DS.
  Decentralized MLS falls back to vanilla MLS. Distributed MLS is not
  as efficient but assumes/allows a vastly more complex network
  topology where there could not be a natural use case.

• Richard: What's missing is guidance for implementers to help them
  decide which of these two things to use.

• Nick: Let's write a third document. It seems like it will be hard to
  merge these documents.

• Richard: I am skeptical of this claim.
• Nick/Britta: Architecture document? (boo hiss)
• Nick: Are the two documents' timelines aligned?
• Sean: Chairs will have to forge consensus between authors to find a
  way forward.

LeafOperationIntents (Konrad Kohbrok)

• Leaving MLS groups is tricky sometimes
• Could do "self remove proposals"
• Requires client to have current group state
• Leaf intents allow cleanly removing a group member despite them
  being offline

• Also can remove "associated clients"

• Sean: Who has read this draft? (2 people) Therefore adoption is
  premature.

• Rohan: The motivation should be more clear. How should clients
  handle the leave intents?

• Sean: Would anyone else like to read this?

• Crickets

Virtual Clients (Konrad Kohbrok)

• Virtual client obscures which device is actually being used by a
  user
• Each leaf in an MLS group then itself becomes a group
• "Supergroups" become smaller overall
• Coordinating clients that share virtual client is hard
• Will merge with another document
• MIMI has expressed interest

• Would like to move this toward adoption

• Raphael: Is anyone particularly opposed? If not let's do it.

• Sean: This has been around for a while. Chairs will discuss doing an
  adoption call.

Single Signature Key Packages (Konrad Kohbrok)

• PQ signatures are big. Trying to shave off signatures in the
  protocol.
• Can remove outer key package signature.

• New wire format

• Rohan: Can this just be an extension instead of a wire format
  change? And a zero-length signature.

• Konrad: If that works then yeah.

• Another signature to remove: commits.

• Complex due to MLS framing structure.

• Does the WG want this?

• Britta: Yes, PQ sigs are big. Say more about how you remove commit
  signatures?

• Konrad: Not actually sure how we'd do this. have to closely study
  messages.
• Raphael: An update is a signed commit, contains a signed leaf node.
  We are 99% sure you can remove the outer commit.
• Raphael: We'd have to re-do a lot of framing and layering. That's a
  lot of work. We need to know if this is worthwhile.

Old individual drafts (Rohan Mahy)

• SD-CWT and SD-JWT as MLS credentials is relatively straightforward
• Could do a more compact and nicer binary repr instead of base64
• Include pending proposals in external commits
• What if you make the DS hang on to proposals so it can send them
  with groupinfos?

• This lets us stop doing workarounds

• Raphael: (note taker had difficulty following this)

• Britta: Does the design affect traceability from AS?

• Rohan: No, doesn't change AS' view. Just for the DS.

New individual drafts (Rohan Mahy)

• draft-mahy-private-external: new wire format for private external
  format.
• DS cannot see private external message, group members can.
• Group has a keypair to which messages for the whole group can be
  encrypted

• Must prevent impersonation of groups

• Britta: What are the tradeoffs here? Does the AS get more
  information than before? What harms does this mitigate?

• Rohan: Less traceability. Leaf node of sender not revealed. when
  combined with e.g. OHTTP and PrivacyPass, enables a user to join
  without ever revealing self to anyone but group members. DS sees
  public signature/HPKE key in the group advertisement.

• Raphael: What is the specific threat model? A malicious client
  attacks the DS?

• Rohan: Concern is proving to a new client that it joined the group
  it meant to join.

• Sean: let's continue discussing on list to see if we want to adopt.

• draft-mahy-mls-new-framed-content-tbs

• Group contexts are getting big, this makes them less big

• Raphael: this is similar to getting rid of signatures (from Konrad
  earlier).

• draft-mahy-mls-new-content-types

• clients could skip decrypting messages that are now irrelevant (e.g.
  typing indicators after the fact)

• add new status and ephemeral ratchets that can aggressively fast
  forward through generations

• Raphael: would forward secure exporter work?

• No, we need per-sender ratchet
• Raphael: is the expensive part ratcheting or decrypting?

• Raphael: couldn't application choose to not decrypt without protocol
  support?

• Konrad: why not make content type an extensible IANA registry?

• Are there new ratchets for each type?

• Konrad: Doing something like this would alleviate tedium and
  copy-pasta elsewhere

• Brendan McMillion: This could just be an ephemeral ratchet, do the
  rest at application layer. Consider also a ratchet tree instead of
  linked list for efficiency.

• Sophie Schmieg: application can skip signature verifying and
  encryption on its own.

• Sophie: do the fast-forward instructions leak information? That's
  metadata about the sender (indicates when they sent status updates
  vs. "real" messages).
• This does address a real performance problem in large groups
  (Discords or corps). There anonymity set might be big enough.

• Could do security considerations for small groups.

• Raphael: what kind of messages are these?

• Rohan: Private messages, but the content type is visible.
• Raphael: MLS already has problems with visible metadata.
• Raphael: so you do have to decrypt sender data then

Drafts used by MIMI (Rohan Mahy)

• draft-ietf-mls-extensions
• draft-ietf-mls-ratchet-tree-options: can we adopt?
• Sean: who has read it? (some hands)
• draft-ietf-mls-semiprivatemessage

Compatibility of MLS extensions (Rohan Mahy)

• 24 defined extensions.
• Anything with a new wire format can't work with other new wire
  formats

• What does this mean for composing extensions? Is this a bad
  situation for deployments?

• Raphael: perhaps authors of drafts should take a look at compat with
  other drafts to raise accuracy of the table?

• Rohan: there's a decent amount of green here

• Tim Geoghegan: is there a test harness for all this?

• Rohan: no

Wrapping up

• Sean: chairs to figure out what drafts to send adoption calls for
• Sean: please chime in more on the mailing list re: adoption calls
  and LCs