You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/proposals/2870-protect-acls-from-reda...

4.2 KiB

MSC2870: Protect server ACLs from redaction

Server ACLs are a way to prevent malicious/untrusted homeservers from participating in a given room. These ACLs are represented by a state event which is easily capable of demolishing all useful functionality of a federated room. Typically this sort of design flaw would be worked out during the MSC process, and in this particular case it was acknowledged as a potential source of accidental mistake, however the impact of making a mistake appears to be larger than anticipated.

Specifically, the ACLs do not default to allowing all servers when they are set but missing an allow field. When an allow rule is missing, it means that all servers can no longer participate in the room. The natural reaction to such a disaster is to try sending a new ACL event, however all the receiving servers rightly refuse the event because the specification says so and it's not yet possible to tell if a trusted server is publishing the new ACLs (due to the social nature of the problem space rather than the technical side). Redacting a server ACL event causes the event content to become {}, which means no allow rule is present.

Proposal

In a future room version, the allow, deny, and allow_ip_literals fields of the m.room.server_acl state event are protected from redaction. Typically this measure is only taken when a field is critical to the operation of the protocol, such as in the case of protecting power levels from redactions. ACLs are not as critical to the protocol as most of the other protected event fields, however the consequences of accidentally redacting a server ACL event are disproportionately large.

Potential issues

None foreseen - this MSC should remedy a problem encountered in the wild.

Alternatives

We could instead dictate that a lack of allow rule implicitly means allow: ["*"], however this is a behavioural change which is easily missed between room versions. We could also define that {} means applying the same mechanics of ACLs when the state event isn't set, however again this is subject to being missed as a behavioural change. Behavioural changes are hard to represent in the specification as room versions are not meant to contain information about how a room might react in the eyes of a room administrator or client implementation, where possible. They are more intended to change server-side algorithms, like the redaction algorithm, to change the functionality under the hood without impacting the room administrator's understanding of their room's function.

Another possible approach is to have servers prevent sending faulty ACL events by preventing their local clients from doing so, such as by rejecting redaction requests. This doesn't solve the issue over federation, but can reduce the likelihood of such events making it to the federation layer. This is what Synapse currently does to help mitigate the issue. This is only effective if the server (or client, locally) implements it - it's common for both clients and servers to forget to add these checks during development, leading to occasional room breakage. This MSC instead tries to resolve the issue more completely for future room versions, pending replacement of ACLs entirely.

Meanwhile, MSC4124 exists as a possible permanent replacement for ACLs.

Security considerations

It may be desirable to redact server ACLs due to abusive server names needing to be banned. Clients are encouraged to not display the differences to the ACLs without the user opting in to seeing the changes (such as by clicking a 'show details' link).

Of particular note is that redacted events may be provided to future users/servers, regardless of the history visibility settings. If fields are protected from redaction, this means they will be visible to those future joiners. This may be undesirable in some circumstances. This MSC does not attempt to address this concern.

Unstable prefix

Implementations looking to test this MSC before it lands in a released room version can use org.matrix.msc2870 as the room version, using room version 11 as a base.