MIMI Interim October 2

RBAC (Rohan Mahy)

• Room policy defined in terms of roles which can be granted
  capabilities
• Capabilities are grouped into groups like membership, moderation,
  messages, etc.
• Each room has its own roles and hence policies (i.e. a user can have
  different roles in different rooms)
• Eventual WG goal is real-time media, and so we need capabilities for
  this kind of thing.
• Editor's copy of the relevant draft has been updated:
  https://rohanmahy.github.io/mimi-room-policy/draft-mahy-mimi-room-policy.html

Richard Barnes: I don't think we need to exhaustively enumerate the caps
right now, let's just focus on devising a framework.

Raphael Robert: How can we meaningfully distinguish between types of
media (image vs. video vs. link) in the presence of E2EE?
Rohan: That kind of thing would have to be implemented in clients.
Raphael: What's the difference between a direct message and a targeted
message?
Rohan: DMs are for a specific individual, targeted messages are for some
subset of a group.

• Roles can be defined in terms of other roles (i.e. "admin gets to do
  everything that a moderator does plus this list of caps")

Tim Geoghegan: Policies can be defined in terms of other roles or
groups. What's the canonical representation of these things?
Rohan: Room policy would have an array of groups in it.
Groups/roles/etc. are identified by a string (usually human readable)
that is unique per-room.

• Policies include role constraints. e.g. can require that a room must
  have a minimum number of administrators.

Tim: Is it possible to have dual control over operations?
Rohan: No, not obviously with what we have here.
Tim: This would be hard to do because multiple approvals/dual control is
stateful.

Timo Kosters: Is canReceiveMessage enforce by the hub and followers? Or
do clients need to remove the user from the MLS state?
Rohan: Yes, enforced by both. Hub could not fan out such messages. A
well behaving client shouldn't display messages if it has lost
canReceiveMessage.

Britta Hale: Are the roles committed to/bound in any way (such as the
hub signature over the assignment)? Usually access control is not bound
cryptographically, but some of these have 'super powers' so to speak
that may want to be more directly authorized in that way.
Rohan: The roles are in the participation list and the role that a user
is joining the room as is in the AddSync and thus shows up in the
cryptographically protected state.

MIMIMI: Details (Konrad Kohbrok)

• Updates have landed to the MIMIMI document. Let's look at
  pseudonymity.
• Participants wishing to communicate exchange connection keys.

Richard: Is the connection key transmitted OOB from MIMI?
Konrad: We should work out an in-band means of doing it. For now let's
assume the users have exchanged connection keys.

• Alice publishes a pseudonymous credential, signed with a key placed
  in an encrypted identity link

Alissa: Alice has one pseudo cred per client?
Konrad: No, per key package.
Richard: Sounds like one per device, per group?
Konrad: Yes. Also potentially some leakage across groups (due to last
resort key packages).

• Identity link wrapper keys are sampled, eventually from the MLS tree
  but that construction is not yet specified.
• Identity link wrapper keys are per-group(/room)
• Identity link key is encrypted under identity link wrapper key.
• Resulting ciphertext goes into AppSync state.
• For Alice to add Bob to a room, she adds Bob's encrypted identity
  link key to the Commit
• Bob can now derive Alice's identity link key and verify that the
  pseudonymous credential resolves to Alice's true cred
• Bob adding Charly (who has no prior connection to Alice) works
  similarly

Rohan: Does Alice check this in Charly's leaf node, or in a real
KeyPackage?
Konrad:

• Dave joins via e.g. a join link that contains the identity link
  wrapper key
• Existing members can then verify pseudonymous cred as above
• User level pseudonymity can be achieved by just not including an
  identity_link_key

Tim: The hub can't be the party that distributed connection keys,
because then it would be able to defeat pseudonymity and the whole point
is to hide user identities from hubs. Does that mean we have to have
some independent PKI for this?
Konrad: Hopefully not. This could piggyback on user connection or
discovery flows that will exist anyway. Alice could discover Bob
(through something we don't know yet) and the resulting record has
connection keys in it.

MIMI Protocol abuse reporting (Rohan Mahy)

• Enumerated key requirements for abuse-reporting

  • Hub can't see message contents unless reported
  • Receiver can't claim a sender sent a message they didn't send
  • Sender can't deny messages
  • Follower hubs can't learn message contents
  • Hubs don't need to retain ciphertext indefinitely

• Based on Facebook's franking scheme

• Sending a hash of context is a privacy leak

  • Follower hub can brute force guess the message contents

• We could solve this by sharing a key between the group members and
  the hub and then using that in a keyed hash

  • Requires some MLS layer stuff

Tim: "Semi-standard"?
Rohan: We need MLS to expose some way to get a key that's safe for this
kind of usage, but it doesn't need to be specifically tailored to this
MIMI use case.
Alissa: How do you represent a hub at the MLS layer?
Rohan: