MSC4245: Immutable encryption algorithm

[turt2live]

Rendered

---

Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published under my Director of Standards Development hat, with a focus on interoperability between existing systems.

---

Dependend on by:

• [WIP] MSC4244: RFC 9420 MLS for Matrix #4244

[turt2live]

Implementation requirements:

• Client
• Server (to prevent clients making mistakes)
• A rollout plan

[dkasak]

I would like to see immutable encryption in all rooms, not just MLS rooms, and potentially even make it non-optional in future room versions. Changing the encryption protocol for a room from a server-controlled setting is inherently problematic and almost never useful.

Indeed, clients today mostly ignore any changes in the room encryption algorithm after they've observed the first m.room.encryption event. This means the existence of the algorithm field only risks client splitbrains without actually serving any purpose.

Placing the algorithm in the create event would ensure uniqueness because to change it, you'd have to be in a different room. This also hints at the natural way to change the algorithm: room upgrades.

[turt2live]

this proposal isn't MLS-specific, fwiw. It's just using MLS as a driver. The encryption_algorithm could also be a megolm string, making that room stuck on megolm.

The rationale for optionality is to allow existing rooms to continue "upgrading" from unencrypted to encrypted, while setting a standard for future rooms to use. As we see uptake (and critically, problems/cheers as a result of the immutability), we could remove m.room.encryption's algorithm field.

[dkasak]

this proposal isn't MLS-specific, fwiw. It's just using MLS as a driver. The encryption_algorithm could also be a megolm string, making that room stuck on megolm.

Great!

The rationale for optionality is to allow existing rooms to continue "upgrading" from unencrypted to encrypted

I'm not sure that the benefits outweigh the costs, so I'm raising this as an early request to look into whether we might want to be more proactive on this front. The encryption algorithm is very much something that should be baked into the room / group, and there should be no opportunities for participants to disagree on whether the room is encrypted or not and using which algorithm.

The modern Matrix approach is to rely on room upgrades more heavily, so it's really hard to come up with a convincing reason why encryption, of all things, should be left malleable, with all the downsides that carries.

[neilalexander]

The rationale for optionality is to allow existing rooms to continue "upgrading" from unencrypted to encrypted

... which is fine when all participants are behaving and have accepted the m.room.encryption event, but due to the eventually consistent nature of Matrix, that's not guaranteed to happen immediately or even within any reasonable timeframe. Worse is that someone who enables encryption on a room has no visibility whatsoever into whether other participant servers are consistent or not until one of their users sends a message, by which time a leak could have happened in plain-text.

I can see value in just deprecating m.room.encryption altogether in favour of an approach like this.

[neilalexander]

One possibility is to extend the auth rules so that an m.room.encryption event will only be accepted if either the create event doesn't specify an algorithm or if the algorithm matches the one specified in the create event exactly.

[andybalaam]

What if encryption_algorithm is null? It would be good to be explicit about this, even if the answer is that it's the same as any other unrecognised value.