MSC4256: RFC 9420 MLS mode Matrix

[dklimpel]

Rendered

Server/Synapse implementation:

• https://gitlab.opencode.de/bwi/bundesmessenger/mls/synapse-mls

Client implementation:

• https://gitlab.opencode.de/bwi/bundesmessenger/mls/mls-test-client

Related to:

• [WIP] MSC4244: RFC 9420 MLS for Matrix #4244
• MSC4245: Immutable encryption algorithm #4245
• MSC2883: [WIP] Matrix-flavoured MLS #2883

[benkuly]

What about display name and avatar url of members? Are they stored in the MLS group context too? And if so, how to prevent malicious users from changing them.

[dklimpel]

Thank you, there will be a section on this here.

[Johennes]

Would we need to enforce that entries from powers also appear in can_propose to enable the process described in "Commit handling with multiple servers" below?

[dklimpel]

Technically that is optional, since events can either be sent as a proposed commit or directly. Ideally every server can propose though, although the first power server really doesn't need to.

[Johennes]

Redactions are not only relevant in the context of data privacy but also for moderation. Not being able to delete malicious or illegal content seems like a significant problem. 😕

[uhoreg]

I've only read through part of this, but here are some (mostly nitpicky) comments so far. Generally, there's inconsistency between using "mls" and "MLS". It would be nice to use "MLS" everywhere.

[uhoreg]

Can you give some rationale here for why you're using CBOR?

[uhoreg]

Also, is this CBOR-encoded data the only thing in the authenticated data, or are there other things that are in there alongside it?

[dklimpel]

JSON would have some overhead when putting it directly into the bytes here, so CBOR seemed like the more natural fit, but it isn't really a requirement. We can change that.

Currently there are no other fields in the authenticated data. There is a way to structure extensions using authenticated data, that we aren't using here yet, which could be more appropriate? But so far we decided to go with the simplest approach.

[uhoreg]

I don't see anywhere in this MSC that mentions where the epoch comes from. I think it may be helpful to mention something about that somewhere, since this MSC will be read by people not completely familiar with MLS. (It comes from the ciphertext, which despite being called "ciphertext", contains some cleartext bits, including the epoch. Which means that servers will be expected to be able to parse the MLS ciphertext, at least enough to read the epoch, group ID, and anything else that's needed.)

[dklimpel]

Yep, exactly what they said and we should put that somewhere

[uhoreg]

Shouldn't the epoch of the ciphertext be equal to the epoch of the current m.mls.commit event (which I assume means the m.mls.commit event that is referenced in the event's auth_events)? Otherwise you're encrypting with an epoch that hasn't been created yet?

[uhoreg]

Is there a way for clients to ask to be re-added? How do others know that the client needs to be re-added?

[dklimpel]

A client can be re-added by reinviting them. Usually there is no way to know this for certain, but clients can likely guess a client got dropped from the room by looking at the results of state resolution. But that is unreliably to do over federation, as you can't always know what fork a room ended up on on that server.

[uhoreg]

Can you explain what this "manual communication" would entail? Are users going to have to talk to each other out-of-band and poke at the cryptographic state in their clients?

[dklimpel]

Yes, the users must exchange information out of band. This can be by email, face to face or another intact or private room or similar.

[uhoreg]

How are user's new devices/deleted devices handled? Who is in charge of adding/removing them from the group? How do people leave the group?

[dklimpel]

Users can add their own devices as part of the verification process during login or other users might propose adding them, when they notice the new device and can verify it.

For leaving users can propose a self removal (if that extension is enabled) or ask someone else to remove them from the group via normal communication in the room.

[uhoreg]

Just to be clear, I believe that this means that having the state in the GroupContext means that the entire state will be encoded in every single commit.

[dklimpel]

Yes, but that's a known issue and can be resolved with MLS extensions. Either a custom extension that only sends a diff, or by using mechanisms from the extensions draft.

However if there is no state change, no proposal for that needs to be sent, so it also isn't included in the commit.

[uhoreg]

What happens if multiple people on that first server send a commit state event at the same time? Does he server just select one to accept and return an error to the others? If so, what error code does it use?

[dklimpel]

That's the regular MLS conflict case. The server selects one based on some criteria (e.g. the one that came first) and sends a rejection message to sender of the other commit.
That needs of course a message. But I don't think we defined the error messages/codes for any of the failure cases yet.

[uhoreg]

I think that the possible delay in applying a commit due to "powers" servers being offline is a significant potential issue that should be listed here. For example, if the first server listed in "powers" is offline, then when you invite someone, it will take 5 minutes before they can actually be in the room. (Could they end up being halfway in the room, if the inviter closes their client after they try to invite, but before they see the commit event?)

This, combined with encrypted state, may also cause problems for MatrixRTC, which IIRC uses various state events. If it takes over 5 minutes to set up a call, or for someone to join a call, that could be problematic.

[dklimpel]

This MSC expects that the servers in the powers list are online.

[uhoreg]

Membership modifications aren't the only reasons for sending commits, though. Group members are expected to periodically send commits (or Updates which are committed by others), which will probably be more frequent than membership changes.

[dklimpel]

There's no requirement to regularly send commits.
However, it's recommended for security. But that's a membership modification as well because updating the own leaf nodes changes the leaf node and such the membership.
But maybe it should be made clear here that any change of leaf nodes in the tree is meant.

[uhoreg]

This nearly tripped me the first time I read it, so a note for future readers: in the current existing room versions, if a server wants to send an event to a room, it needs to use a user ID of a room member that is on that server to send the event. However, in rooms covered by this MSC, there is no sender field, so servers can send events on their own, without needing to invoke a user ID.

[uhoreg]

I don't see any definition of how the Welcome message is sent as a to-device event (e.g. what event type it uses, what properties the event has). Can you add that?

[dklimpel]

They are just normal encrypted events:

{
  "type": "m.room.encrypted",
  "content": {
    "algorithm": "m.mls.v1....",
    "ciphertext": "<encrypted_payload_unpadded_base_64>"
  }
}

[richvdh]

What would be the impact if the invite was not sent, for example due to a buggy or malicious client, or due to a network error? It seems like the MLS membership list and Network membership list would get out of sync, which could be problematic?

[richvdh]

Relatedly, is there any risk of a buggy client sending an invite without having sent a welcome message?

[dklimpel]

If you get a welcome message but no invite, you can just ignore it. It is like getting a megolm key for a room you are not in. If a user sends out an invite without a welcome, then you need to talk to them and fix the bug or put them on your ignore list.

[richvdh]

Given that member events are not used, how does network membership (invites, joins, etc) propagate between the homeservers that are participating in the room?

[dklimpel]

Only the local server needs to know which of its users are in the room. Invites and joins are handled using the existing federation APIs for invites and joins, but other servers never get told about those users, they only know which servers are participating.

[richvdh]

Is this not subject to manipulation by a server wishing to put itself in charge of applying commits, by falsifying origin_server_ts?

[dklimpel]

In that case the higher power server could still send a conflicting event, which would win during state.

[richvdh]

My understanding of this section is that a netsplit of any non-trivial duration can lead to different commits being applied on each side of the split; when the split is eventually resolved, this will result in one side "losing" and any clients on the losing side will be effectively excluded from the room, since they will have discarded the necessary MLS state.

If that's correct, it feels akin to the "state reset" problems that current Matrix can suffer from, but much worse.

This seems very dangerous to me. IMHO it would be better not to allow MLS commits outside the current highest power server at all.

[dklimpel]

Yes, that is expected. If you want to prevent such conflicts, you should only put a single server into the power list, which achieves the same result as only allowing commits from the highest power server. The option to add more servers in the powers list only exists for the cases where people expect servers to go offline eventually (like in smaller communities, where a friend decides to quit Matrix).