3757-restricting-who-can-overwrite-a-state-event.md

MSC3757: Restricting who can overwrite a state event.

Problem

Currently there are three main ways to limit who can overwrite a state event:

• If a user's PL is greater than the m.room.power_levels state_default field
• If a user's PL is greater than the m.room.power_levels events field for that event type
• If a state event has a state key which begins with an @, then the sender's mxid must match that state key.

This is problematic if a user needs to publish multiple state events of the same type in a room, but would like to set access control so that only they can subsequently update the event. An example of this is if a user wishes to publish multiple live location share beacons as per MSC3489 and MSC3672, for instance one per device. They will typically not want other users in the room to be able to overwrite the state event, so we need a mechanism to prevent other peers from doing so.

Proposal

Therefore, we need a different way to state that a given state event may only be written by its owner. We propose that if a state event's state_key starts with a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event. This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid exactly equals the state_key.

As the spec currently enforces a size limit of 255 bytes for both user IDs and state keys, the size limit on state keys is increased to 511 bytes to allow prefixing any currently-valid state key with a maximum-length user ID (and a separator character). The size of a state key suffix after a leading user ID and the separator character is limited to 255 bytes so that any such suffix may follow any user ID without the complete state key ever surpassing the total state key size limit. Similarly, the size of a state key without a leading user ID is limited to 255 bytes so that any state key without a leading user ID may be given one without ever surpassing the total size limit.

We also allow users with higher PL than the original sender to overwrite state events even if their mxid doesn't match the event's state_key. This fixes an abuse vector where a user can immutably graffiti the state within a room by sending state events whose state_key is their matrix ID.

Practically speaking, this means modifying the authorization rules such that rule 8:

8. If the event has a state_key that starts with an @ and does not match the sender, reject.

becomes:

8. If the event has a state_key:
   1. If the state_key starts with an @:
      1. If the prefix of the state_key before the first _ that follows the first : (or end of string) is not a valid user ID, reject.
      2. Otherwise, if the size of the state_key without the leading user ID is greater than 256 bytes, reject.
      3. Otherwise, if the leading user ID does not match the sender, and the sender's power level is not greater than that of the user denoted by that ID, reject.
   2. Otherwise, if size the state_key is greater than 255 bytes, reject.

Note that the size limit of 256 bytes after a leading user ID includes the separating _.

No additional restrictions are made about the content of the state_key, so any characters that follow the sender + _ part are only required to be valid for use in a state_key.

For example, to post a live location sharing beacon from MSC3672 for one of a user's devices:

{
    "type": "m.beacon_info",
    "state_key": "@stefan:matrix.org_{deviceid1}", // Ensures only the sender or higher PL users can update
    "content": {
        "m.beacon_info": {
            "description": "Stefan's live location",
            "timeout": 600000,
            "live": true
        },
        "m.ts": 1436829458432,
        "m.asset": {
            "type": "m.self"
        }
    }
}

Since : is not permitted in the localpart and _ is not permitted in the domain part of an mxid (see Historical User IDs), it is not possible to craft an mxid that matches the beginning of a state key constructed for another user's mxid, so state keys restricted to one owner can never be overwritten by another user.

Potential issues

Incompatibility with domain names containing underscores

Although both the spec and RFC 1035 §2.3.1 forbid the presence of underscores in domain names, there noneless exist resolvable domain names that contain underscores. The proposed auth rule for parsing an MXID prefix from an underscore-separated state key would fail on such domain names.

Possible solutions include:

• using a different character to terminate an MXID prefix in state keys. The character must be one that's known to be absent from domain names in practice, and must also not be any character that the spec allows to appear in a server name.
• refining the proposed auth rule for parsing an MXID prefix such that it does not fail on domain names that contain an underscore. One way to achieve this is to leverage the absence of underscores from top-level domains.

Alternatives

MSC3489 and MSC3672 originally proposed that the event type could be made variable, with an ID appended to each separately posted event so that each one could separately be locked to the same mxid in the state_key. However, this is problematic because you can't proactively refer to these event types in the events field of the m.room.power_levels event to allow users to post them - and they also are awkward for some client implementations to manipulate.

An earlier draft of this MSC proposed putting a flag on the contents of the event (outside of the E2EE payload) called m.peer_unwritable: true to indicate if other users were prohibited from overwriting the event or not. However, this unravelled when it became clear that there wasn't a good value for the state_key, which needs to be unique and not subject to races from other malicious users. By scoping who can set the state_key to be the mxid of the sender, this problem goes away.

MSC3760 proposes to include a dedicated state_subkey as the third component of what makes a state event unique. As an extension to this idea, a comment in the discussion of this MSC proposes allowing state_key to be an array of strings. Either proposal allows for effectively including an owning user ID in a state key without having to string-pack the user ID with another string. However, either proposal would alter the nature of state events and state resolution.

Another comment in the discussion of this MSC proposes an optional top-level field for both state and non-state events that designates ownership of the containing event to a particular user. This would provide ownership semantics for not only state events, but also message events, which may be used to restrict event replacements / redactions to only the designated owner of an event. However, it remains to be decided how using this top-level field for state events should affect state resolution; namely, whether it is possible to set multiple events with the same state_key but different owners.

Security considerations

This change requires a new room version, so will not affect old events.

As this changes auth rules, we should think carefully about whether could introduce an attack on state resolution. For instance: if a user had higher PL at some point in the past, will they be able to abuse somehow this to overwrite the state event, despite not being its owner?

When using a state_key prefix to restrict who can write the event, we have deliberately chosen an underscore to terminate the mxid prefix, as underscores are not allowed in any form of server name (either a DNS name or IPv4/6 address, with or without a numeric port specifier). A pure prefix match will not be sufficient, as @matthew:matrix.org will match a state_key of form @matthew:matrix.org.evil.com:id1.

This changes auth rules in a backwards incompatible way, which will break any use cases which assume that higher PL users cannot overwrite state events whose state_key is a different mxid. This is considered a feature rather than a bug, fixing an abuse vector where users could send arbitrary state events which could never be overwritten.

Unstable prefix

While this MSC is not considered stable, implementations should apply the behaviours of this MSC on top of room version 10 or higher as org.matrix.msc3757.

Dependencies

None