matrix-doc/proposals/4084-mass-redactions-alterations.md

MSC4084: Improving security of MSC2244

MSC2244 introduces an idea of "mass redactions", where a single redaction event can target more than one event. This provides significantly improved performance when dealing with large volumes of spam or redacting one's own messages, but is also irreversible.

This proposal amends MSC2244 to accommodate previously-undisclosed security considerations.

Background context

MSC2244 was accepted through FCP under an older process where implementation was not required before FCP. Some time later, the SCT noted significant process overhead when implementation happens second, so updated the process to require implementation before FCP can begin. MSC2244 however had already finished FCP at the time - it's now stuck in a state where FCP is completed, but the MSC is not accepted because it is not implemented.

Implementation on MSC2244 was blocked on internal security context from the SCT as of March 2022, despite the MSC successfully completing FCP in November 2019. The concerns, now captured by this MSC, were discovered through a brief attempt to implement the MSC during development of another feature.

After some unintended process delays, this MSC exists to cover the internal context captured throughout 2022.

With the new process in place, issues like the ones covered by this MSC are easier to catch before an MSC is accepted then merged. Unfortunately, because of the older process in play, the MSC needs to be modified by another MSC first - namely, the MSC described by this document.

Unstable implementation

Under the older process MSC2244 falls under, implementation can happen after FCP is completed. To qualify as "accepted", the MSC will need such an implementation and review from the SCT before it can continue. It's not until the MSC is assigned a stable room version that it becomes merged to the specification, and unstable identifiers (including the unstable room version) can be dropped.

Acceptance on MSC2244 is additionally qualified on resolution of the concerns described in this MSC, though the exact solutions may vary. Once both implementation and security considerations are made, the SCT will mark MSC2244 as accepted. The MSC would then qualify for inclusion in a (future) stable room version.

Problem

MSC2244 provides room moderators a way to redact multiple messages in a single event, reducing overall traffic and therefore speed of removal. This is an incredibly useful tool when dealing with volumetric spam - the sender is not required to generate the same volume of redactions (an amplification attack).

Mass redactions can also be used to remove an entire user from the conversation history, either electively or by choice of a room moderator. When performed electively, the user is essentially trying to erase their presence from the network/room. Though some metadata is retained, the conversation history is completely destroyed in this scenario. This causes two problems of varying severity:

1. A choice has been imposed upon other members of the room, where their copy of the conversation has been altered. Matrix is structured with a belief that everyone has an equal right to the conversation, and a built-in tool which easily allows that conversation to be altered is not ideal. However, servers wishing to perform such a function on behalf of their users are already able to remove/disable rate limits on sending individual redaction events. Many servers over the years have elected to do exactly that to erase a user from the network as best as possible. Therefore, for the purposes of this MSC, it is considered a non-issue to support mass redactions in Matrix.

2. As mentioned above, mass redactions can be used by servers to erase as much of a user's footprint as possible. With redaction events supporting approximately 1500 targets and large public rooms typically having ~2000 messages per sender on average, a user can erase themselves in a few dozen events. This is an irreversible action undertaken by the user, and well within common rate limits for servers. Therefore, this action should be treated as a form of deactivation and require confirmation of identity before going forward with it, as a malicious user may have acquired the access token for the user. This MSC proposes changes to MSC2244 in line with this idea.

Further, MSC2244's authentication and acceptance rules for the new m.room.redaction event are unclear, potentially allowing for a client to redact events which are not legally possible to redact with the original event. The MSC tries to ensure clients are not made aware of event IDs that the server does not have itself (or which are illegally included in the array), though it's theoretically possible for a client to gain access to the unmodified m.room.redaction event and redact the illegal targets anyways. This MSC proposes changes to how MSC2244 handles redactions to eliminate potential points of abuse/trickery from malicious actors.

Proposal

To help ensure that malicious actors are not able to effectively deactivate a user's account, the existing PUT /_matrix/client/v3/rooms/:roomId/send/:eventType/:txnId endpoint MUST NOT accept m.room.redaction events in room versions supporting mass redactions. The server MUST respond with a 400 HTTP status code and M_BAD_STATE error code for this condition. Clients are still able to redact individual events at a time using the /redact endpoint, if desired.

To ensure that clients are able to actually use mass redactions, a copy of /send is introduced with User-Interactive Authentication (UIA) optionally used by the server. The new PUT /_matrix/client/v4/rooms/:roomId/send/:eventType/:txnId endpoint moves the event content from the top level down into a content key. At the top level is the required auth key from UIA. Clients SHOULD NOT provide auth on the first request (per event type and transaction ID pair), as the server might not require UIA. If the server does require UIA, it will respond with the normal 401 and stages information described by UIA - the client would then be required to repeat the request with the added auth.

In examples, the request flow may look like the following:

> PUT /_matrix/client/v4/rooms/!example/send/m.room.redaction/1234
> Authorization: Bearer accesstoken
> Content-Type: application/json

{
  "content": {
    "redacts": [/* ... */]
  }
}

< HTTP/1.1 401 Unauthorized
< Content-Type: application/json

{
  "completed": [],
  "flows": [{"stages": "m.login.password"}],
  "params": {},
  "session": "abc"
}

> PUT /_matrix/client/v4/rooms/!example/send/m.room.redaction/1234
> Authorization: Bearer accesstoken
> Content-Type: application/json

{
  "content": {
    "redacts": [/* ... */]
  },
  "auth": {
    "type": "m.login.password",
    "identifier": {
      "type": "m.id.user",
      "user": "@self:example.org"
    },
    "password": "CorrectHorseBatteryStaple",
    "session": "abc"
  }
}

< HTTP/1.1 200 OK
< Content-Type: application/json

{
  "event_id": "$whatever"
}

Alternatively, if the server does not require UIA to send the given event, the 401 intermediary error can be skipped, as demonstrated below:

> PUT /_matrix/client/v4/rooms/!example/send/m.room.redaction/1234
> Authorization: Bearer accesstoken
> Content-Type: application/json

{
  "content": {
    "redacts": [/* ... */]
  }
}

< HTTP/1.1 200 OK
< Content-Type: application/json

{
  "event_id": "$whatever"
}

When a server decides to apply UIA is left as an implementation detail. It is recommended that at a minimum servers require UIA for a user to redact more than 25 of their own events in a single redaction event. Other restrictions are not currently suggested, though in future more event types may require UIA in order to be sent.

The existing PUT /_matrix/client/v3/rooms/:roomId/send/:eventType/:txnId endpoint is additionally deprecated by this proposal. Note that besides the change in request body to support UIA (and associated error condition), the request is otherwise unchanged.

MSC2244's authorization rules and redaction handling are additionally replaced to be in line with room version 3 and greater. Instead of sending a filtered redaction event down to a client, the redaction event is withheld until all target events are known by the server, and are valid targets. The server SHOULD attempt to retrieve unknown target events from other servers in the room with appropriate backoff to avoid needlessly delaying the redaction's effect.

This approach helps diminish the impact of a redaction event targeting future or deliberately missing events causing future issues in clients, servers, and conversation history. Further, by assuming that a server listing an event ID in the redaction means they have knowledge of that event ID, the sender is discouraged from including known-invalid entries. They would be the first server to be contacted when every other server is attempting to locate that missing event.

Servers should note that a malicious server may still include deliberately malicious entries to consume time spent retrying (and failing) on every other server, slowing them down. Servers should give up trying to locate missing target events after a reasonable period of time. Specifics are left as an implementation detail.

Potential issues

UIA is theoretically going away or changing with the OIDC work from the core team. This proposal makes the transition harder or at least more verbose once OIDC is ready. Ideally, the fewest transitions possible would be performed, though with OIDC potentially being further out than this MSC, it feels appropriate to continue using UIA for now.

This MSC also forces servers to withhold redactions until all target events are received and validated. In the case of volumetric spam, this means a server will be required to first download that spam then redact it. With each event being maximum 65kb in size, this could be significant network traffic. The alternative is a malicious sender could cause future problems or confuse clients due to trivially possible bugs in servers, thus exploiting individual implementation bugs to alter the conversation history depending on viewer.

Alternatives

No significant alternatives not already discussed identified.

Security considerations

This proposal discloses a consideration around mass redaction being the same as deactivation, and identifies a potential security issue relating to malicious redaction events. How these issues are resolved from a security standpoint is described inline by the proposal text.

Unstable prefix

MSC2244 is from a time before an unstable prefix section was included in proposals. This proposal adds one, described here.

While MSC2244 is not considered stable, implementations should use org.matrix.msc2244 as the room version identifier, using v11 as a base. Note that this inherits MSC2244's backwards compatibility clauses as formal specification.

For clarity, the org.matrix.msc2244 room version additionally includes the changes described by this MSC too.

Dependencies

This proposal has no direct dependencies.