Minutes interim-2023-mimi-08: Thu 19:00
minutes-interim-2023-mimi-08-202309281900-00

MIMI Interim 2023-09-28

Note-taker: matthew@matrix.org
Agenda bashing: none

• rlbarnes: Update from the Design Team

• Recap:

  • CSSSC (client-server-server-server-client) architecture is
    unmodified from previous meeting.
  • Assuming that hubs are constant over time, but hub portability
    is punted for now.
  • All communications related to a room go through the hub.
  • This is to accomodate potential lack of full mesh connectivity
    between servers

• Slide 6: New content!

  • In the last call we got stuck on the word 'member'
  • Users in rooms are participants
  • Devices/clients in an MLS group are members.
  • This distinction allows for users who are participants in a room
    may have no clients which are members of the MLS group.
  • "Active participant" has clients which are members of the MLS
    group
  • "Inactive participant" has no clients members of the MLS gruop.

• ekr:

  • Suppose we have an inactive participant of the room who receives
    a welcome message to the group...?

• rohan:

  • I'd say they were active.

• rlbarnes:

  • When the welcome is generated in parallel with a commit...

• ekr:

  • ...

• rlbarnes:

  • When the commit is accepted by the group, then your client will
    be part of the MLS group and you will be an active user.
  • A user can be activated without anyone else providing a key
    package.

• rlbarnes:

  • "Policy envelope" was originally something the hub could
    specify; the bounds of acceptable authorisation policies for the
    room.
  • The stuff right now talks about policies themselves; need to
    revisit the envelope idea which needs more refinement.

• Slide 7: Terminology illustrated

  • There should be mapping between the clients of the MLS group, to
    a given user.

• Slide 8: Preemption

  • One of the consequences of splitting out the room state like
    this, with independent protocols to manage independent bits of
    state is... that each protocol can do what it's good at. MLS is
    good for key management, but not authz policies. Downside is
    that they can get inconsistent though. So having split them out
    and managed them independently, we need to define how these
    things interlock with each other. We've aligned pretty well on
    this preemption rule - there's a hierarchy to these types of
    state. Authz controls the Participant List, and the Participant
    List controls the MLS Group.

• Slide 9: Confirmation

  • Everyone in the room needs the same view of the room state.
  • There might be some time lag, but need to agree with some
    fidelity to the changes.
  • Use the MLS key schedule as a confirmation mechanism.
  • If you inject a value into the key schedule, it gets hashed into
    the state of the MLS group, and thus into all of the keys which
    the clients use, and so if you disagree with that hash you can't
    communicate as all the keys will be different.
  • Therefore you take the whole room state, including auth policy
    and participant list and hash into the MLS key schedule so that
    in order for the group to keep functioning, everyone will need
    the same view.
  • Probably using GroupContext extension. Each commit must reflect
    the current room state.
  • Blue arrows show confirmation via MLS of the participant list
    and thence the authz policy.

ekr:

• The red arrows mean information flows downwards, and blue arrows
  mean "look over here, and incorporate information". The info always
  flows left to right?

rlbarnes:

• Yes.

• Slide 10: Order of Operations

  • These invariants in the last few slides are useful in clarifying
    what we mean, but have implications for how we do stuff.
  • In particular, joins & leaves have to be done in particular
    order.
  • I need to add ekr to a room first as a user, and then the
    devices.
  • As if the MLS add turns up first, it'll get rejected.
  • If removing, it's the reverse; remove all clients before ekr can
    be removed from the participant list.

ekr:

• So, another way to design this system would be that some the
  operator of the service kicks richard out of the group, and triggers
  members of the group to send a commit to kick him out.
• Did you consider this?
• If there were crypto protocols which didn't provide a way to evict
  clients from a group, what would they do? This seems to depend on
  MLS?

rlb:

• It would be clear rather than proactively removing from the
  participant list, while it was pending, to remove the devices - and
  actually remove mark them as later

rohan:

• To MLS or not to MLS:
• The compromise is that there's a lego block of stuff which
  manipulates state & E2EE. In the case of MLS, the MLS chunk for E2EE
  also has a bucnh of stuff that manipulates state. So the stuff you
  need outside of MLS are small, possibly zero. If you did this with
  DR, then the lego block has the same boundaries, and includes
  something which basically does E2EE of sessions - and some other
  stuff which manages the state of the mapping of the participant list
  to specific sessions. So you can totally do this with another
  protocol but you that's not in the charter; but we've been striving
  to make sure that's possible and doesn't blow your head off.

ekr:

• There's really a group decision to be made: are the perimeter of the
  E2EE lego block the things provided by MLS and everyone else has to
  figure it out?

rlb: Yup. next slide!

• Slide 11: Lego Bricks
  • Transport ships things around between servers
  • Blue blocks for protocols for the different types of state
    attached to a room.
  • E2EE block is an MLS-shaped hole. If you want to do this with a
    different protocol, it's up to you to figure out how to build
    the filigrees to integrate. This should be possible though,
    perhaps by relaxing the security properties though.

alissa:

• When you talk about the MLS-shaped hole, does it only touch that one
  box? The drafts feel like they have a lot of interlock - e.g.
  transport would be designed differently without MLS.
• Which parts of this does the hole extend to?
• How much of the architecture is impacted when you say you can do
  this without MLS? "All of it"?

rlb:

• The compartmentalisation objective is that there's not an inordinate
  amount of reengineering to reuse the policy & signalling. If the
  format or transport reuse bits of MLS which you get for MLS for
  free, you can add an equivalent from other encryption schemes.
• MLS is big; if you start from another protocol you'll have to add
  Stuff to fill the same hole.
• The objective is that the changes needed should be relatively small.

rohan:

• My answer is: the policy blue block is independent of protocol. The
  E2EE and signalling blocks touch each other, but they need to be a
  matched pair. The interfaces to the application logic could be the
  same for a matched pair, compared to a replacement DR +
  DR-signalling. Message forwarding relies on E2EE.
• Three bricks get touched by switching crypto is my answer.

tim:

• Granting that we've designed sort of abstraction over a specific
  E2EE mechanism, be that MLS or DR, what does that mean for interop?
• Does that mean that participants need to have agreed OOB if they are
  MIMI or DR?

rlb:

• It means nothing for MIMI. If you're not talking MLS you're off book
  and on your own.
• This allows a transitional plan

ekr:

• We're chartered to use MLS
• MLS should be coupled to an appropriate level; not totally decoupled
  or interwined; set of judgements.
• Not the WG's responsibility to make MLS removable - but doesn't mean
  it has to be made unremovable.

rlb:

• e.g. If someone wanted to make QUIC based on Wireguard, they'd need
  to make Wireguard look like TLS.

konrad:

• We should have version agility anyway, for reasons of good practice.
• This gives you the nego cap.

matthew: For the transitional benefits, I think there is an opportunity
to make the lego blocks interchangable, to help facilitate upkeep of the
protocol. Which helps stops the risk of gatekeepers implementing their
own API for DMA compliance, or some interim solution that doesn't have
the traction of something like MIMI. But if MIMI can support those
transitional use cases, it has a much higher chance of being adopted.

alissa: do you propose any changes to the decoupling that was described?

matthew: I think the proposed decoupling is good. but the "MLS-shaped
hole" terminology might lead to only MLS being able to fit the slot,
instead of protocols that may be more transition-friendly.

• Slide 12: Documents
  • Each lego-brick gets a doc, pretty much.

ekr:

• This diagram shouldn't inform which docs exist, sort-of like
  Conway's law.
• The drafts are too spaced out.

Over to Konrad & Travis...

Travis:

• Scenario discussions is where we're at.

• We have to scenarios to show how the lego blocks interwork:

  • 1. Alice adds Bob
  • 1. Alice leaves group

Scenario 1 Alice adds Bob

• Slide 16: Alice creates* an invite event for Bob
  • Signalling happens "first".
  • Alice creates signalling to add Bob into the room.

• Slide 22: Bob accepts invite
  • Still firmly in signalling territory here
  • and then we head over to MLS

rohan:

• This doesn't resemble at all what I thought we agreed on in the last
  couple of calls.
• What I think we discussed was that the purple signalling would
  happen simultaneously with the E2EE, not as a sequence with
  signalling happening first.

konrad:

• Here we chose the external-commit-based Alice adding Bob. In the
  Welcome-based flow, Alice would probably send the welcome along with
  the 'hey add Bob' signalling message in parallel. We chose this to
  show a signalling-first flow. Moving on:

• Slide 25..29:

...and now MLS layer gets distributed.

rlbarnes:

• Can you comment on where the confirmation happens in this process?

konrad:

• The moment that the hub processes the signalling message that Bob is
  added as a participant (even as an invited state) the hub would
  require that the next commit would already feature the updated
  participant list as part of the group state; either as part of the
  group state as a groupcontext extension or injected as a PSK so that
  whoever does the next commit agrees on the participant list.

rlbarnes:

• The hub would provide the commit that Bob is a member. It seems
  circular but it isn't.

ekr:

• I'm uncomfortable that the hub is doing a bunch of enforcement of
  MLS invariants.
• Is this necessary? What happens if we don't do it?
• To give one example: i add someone but i give them key material
  which is bogus.
• How much is enforced?

konrad:

• The bogus key material is unsolved at the MLS level.

ekr:

• What is the hub verifying this stuff doing? What is the function the
  hub is doing in this protocol?

konrad:

• The hub is verifying that the participant list is injected into the
  room state one way or another. Once the signalling event has reached
  the hub and blessed it and fanned it out to everyone else, it
  ensures it's been reflected in the MLS group. It could be done by
  proposals, and the hub will not accept subsequent commits which
  haven't accepted that proposal. Think of it as a proposal in terms
  of semantics.

ekr:

• What is the function of that? Why not just not do that?

konrad:

• So everyone agrees who's in the participant list.
• This is vital to enforce policy.

rlbarnes:

• At least mechanistically this is not a crazy ask. The reason we have
  a central hub is so it can act as an arbiter of what commits get
  applied, to sequence MLS commits.

ekr:

• That's a non-adversarial function. But this is an adversarial
  setting.
• What state of affairs can you get into where the hub is rejecting
  some set of messages as not matching the state, and can you
  guarantee that the hub can catch all of those situations?

rlbarnes:

• These rules are meant to get written down in the document.
• If the hub wasn't enforcing this, the members could still agree, so
  what's the difference.

konrad:

• We could have agreement based just on the members
• But then an insider in the group could derail it by sending
  malicious commits. But the hub would then take it, whatever, ratchet
  epoch forward, and everyone disagrees and discards it, and the hub's
  now in an inconsistent state. So we try to do as much verification
  on the hub side as possible. Agreed we need to write this down
  formally and which security guarantees we expect.

Scenario 2: Alice wants to leave.

Slide 33-35: signalling flow

travis

• starts with signalling (although it could be stapled together, both
  DS & signalling operations, but split out here for visibility
  purposes - but nothing constraining it to be separate operations;
  they could be happening at the exact same time.)

slide 36-39: MLS flow

rlbarnes:

• Question about the remove flow:
• If room had Alice Bob & Charlie participants
• If you announce Alice had left & her devices have gone, you could
  let Bob & Charlie decide to evict her. Or designate which of them
  should be the committer.

konrad:

• The hub should record that the next commit should remove Alice; if
  she stays there then the hub should reject it.

basel:

• The flow you've mentioned opposite to what was proposed earlier,
  where the clients had to be removed first and then the user later.
  Why?

travis:

• From the signalling perspective it doesn't really matter if Alice
  finds a way to self-evict first from signalling or the MLS group.
  The order doesn't matter, and was presented the same as the previous
  flow for consistency.
• Joins are ordered, Leaves aren't so important.

basel:

• If the clients leave, and the user's still there, then the room's in
  an inconsistent state.

konrad:

• Richard had a proposal for that; a collaborative approach rather
  than a preemptive approach.

rlbarnes:

• On the DT call, the signalling message in advance of Alice's clients
  being removed would not actually remove Alice from the participant
  list. It would put her into an exiting state; the trigger that her
  devices should be removed.
• But it's important to maintain that invariant - Alice should be in
  the plist as exiting even if her devices haven't been removed.

konrad:

• Also Alice can't remove herself due to an unfortunate characteristic
  of MLS.
• Richard's proposal is a good one and we should keep this invariant
  alive.

ekr:

• The invariant at the beginning is that you can't be in a group
  without being a participant.
• Is there a way to get back in that state (inactive member of the
  group) once you've been added?
• e.g. if your phone blows up.

konrad:

• You can go from active->inactive if you have a semantic for whole
  user leaves v. losing all clients.
• E.g. close browser tab (which cleans up your client) but doesn't
  want to use the user from the room.

ekr:

• It feels like a weird security property to let users be 'in' a room
  without devices.
• Don't feel strongly about it; just trying to wrap my head around it.

konrad:

• The question is probably whether we want it as a feature, as a
  producty question.

rlbarnes:

• I'm hopeful that a few folks have reviewed the docs in addition to
  the framework discussed here. if you've done both, you can see
  there's a bit of a disconnect.
• If you think of what stuff we want to adopt, are we heading towards
  the right foundations here?
• Are the docs a good foundation?
• Are the concepts from this call a good foundation?

matthew:

• I think this is a good solution; a good compromise between pure-DS
  and pure-LM which gives a route to pure MLS solution while
  supporting a transitional approach.

ekr:

• This is a good general direction.
• The documentations are a hard-hat area to be honest.
• Had a hard time reading them.
• This is the right direction.
• Adoption call for the architecture document is okay
• Other docs need more work.
• Need another iteration of the docs before proposing adoption.

rlbarnes:

• I feel pretty good about the direction we've got to in the DT
• Need another spin on the docs before an adoption call.
• Of course, always happy to have more opinions in the room though!

alissa:

• Can we hear from people not on the DT on what's been proposed?
• Yes, ekr you're the only one not on the DT who's chimed in so far...
• Just want to make sure everyone has an opportunity.
• We should merge some docs to make them easier to adopt and get some
  semblance of consistency

tim:

• As WG member but not Chair: in favour of consolidation.
• Splits between WGs introduces significant admin overhead; it's a
  pain.
• Heavily in favour of having fewer docs.

konrad:

• at least for MIMI-DS, it'd make sense to have it as a separate doc,
  as MLS isn't sufficient to do messaging in any way shape or form;
  additional components are required, and indeed one of those is a DS.
  So even though we're not chartered for this, having a separate doc
  for describing and designing a DS would be useful outside this WG,
  who want to use MLS but can't come up with their own design. Having
  some sort of reference DS in a more modular way would make sense in
  my opinion.

travis:

• As the author for policy + signalling docs, i think those two can be
  merged quite easily. Transport might be a little more difficult as
  both DS and remaining portions of the stack need a transport, but
  it's possible it could be amalgamated into more of a DS protocol
  stack. So I agree with that approach. I think we can reduce the
  number of docs, but not down to 1.

ekr:

• The argument for getting down to 1 seems to be "let's get everything
  in one place" for referencing parts of the doc.
• I'd rather it was readable, in whatever configuration.
• If someone has a treatment where MIMI-DS is broken out then great,
  but i'd want to see that.

rlbarnes:

• We've had a pattern in TLS for people referencing subsections bits
  of TLS without them being split out.

alissa:

• DT: you have some agreement around some level of consolidation,
  maybe not all. Maybe you can work that out in the DT and come back
  with it.

rlbarnes:

• Clear feedback heard that fewer docs are preferable.
• We'll take the feedback we've got today and put them into the docs
  and consolidate them together.

alissa:

• We've had a good discussion today about integration with MLS with
  flexibility for folks to go off and do their own thing if they have
  an MLS-shaped hole.
• The way this is presented in the docs isn't consistent with the
  charter, as the charter assumes MLS for use of key establishment. We
  need to be strict that that's what people put in the docs and ditch
  the language about about how we're doing this purposefully to let
  people switch crypto blocks. RFCs are immutable.

matthew:

• Sure. But we should make the E2EE crypto block modular so MLS can be
  swapped for MLS-shaped holes, otherwise that flexibility will easily
  erode.

rlbarnes:

• Precedent: RFC9000 QUIC is separate from RFC9001 "Using TLS to
  secure QUIC"

ekr:

• If it makes this unreadable, then don't break it up.

matthew:

• We really need an E2EE shaped block rather than a MIMI-DS shaped
  block, to make it more substitutable. Doesn't help folks wanting to
  use MIMI-DS as a MLS-DS spec though.

konrad:

• Agreed. We'll give it a go; let's see how it goes.

alissa:

• What about the arch doc?

rlbarnes:

• I'd keep it separate - there's a precedent with MLS.
• It needs to go ahead of the protocol docs

ekr:

• Or it could be a nice intro to a consolidated doc
• How much material are you duplicating?

matthew:

• Architecture docs ftw, if you have other docs to index.
• +1 to Richard

rohan:

• Ditto.
• Arch is a "how", the other docs are the "what".
• I like the Arch doc being separate.

alissa:

• We can revisit this next time once the other docs are done and
  decide which docs get done in which calls.

rlbarnes:

• concur.

alissa:

• Doodle plan for October coming together.

tim:

• Thanks to DT

alissa:

• Thanks to DT too, and to the awful notetaker.

rohan:

• thanks!