Skip to content

MSC4263: Preventing MXID enumeration via key queries #4263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

MSC4263: Preventing MXID enumeration via key queries #4263

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions proposals/4263-prevent-mxid-enumeration-via-key-queries.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Server

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

element-hq/synapse#18180

Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# MSC4263: Preventing MXID enumeration via key queries

The client-server API allows searching users and querying their profiles via
[`/_matrix/client/v3/user_directory/search`] and
[`/_matrix/client/v3/profile/{userId}`], respectively. Both of these APIs can
among others be abused to enumerate MXIDs. Servers are, therefore, only required
to return results for users who either share a room with the requesting user or
are a member of a public room known to the server. In all other cases,
homeservers can respond with 403 or simply omit the user from the response.

Similarly, on the server-server API, servers are generally permitted to deny
requests to [`/_matrix/federation/v1/query/profile`] with 403.

The [`/_matrix/client/v3/keys/query`] and
[`/_matrix/federation/v1/user/keys/query`] endpoints have a similar problem but
do not currently permit server admins to restrict their responses to conceal
users.

This proposal carries the behaviour of the user directory and profile APIs over
to the key query APIs.

## Proposal

When processing [`/_matrix/client/v3/keys/query`] requests, homeservers MUST at
a minimum consider users who share a room with the requesting user or are a
member of a public room. This is regardless of the concrete membership value of
the queried users in those room.
Comment on lines +24 to +27
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem you will run into with this, is that currently you can encrypt for a user you have only invited. In theory an invite can also enumerate mxids, since if the invite succeeds, the user likely exists. But that can be restricted using policies on a server currently. However not being able to query keys for a user, that is already invited to a room will prevent them from being able to decrypt those messages.

Additionally some clients currently use key queries to enable encryption for a room. This might not be possible anymore with this change, leading to those rooms not supporting encryption anymore. Clients could change that to always enable encryption without checking if encryption is possible, but that likely will need a transition period?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem you will run into with this, is that currently you can encrypt for a user you have only invited. In theory an invite can also enumerate mxids, since if the invite succeeds, the user likely exists. But that can be restricted using policies on a server currently. However not being able to query keys for a user, that is already invited to a room will prevent them from being able to decrypt those messages.

I think this should be covered by the "regardless of the concrete membership value of the queried users" clause. Though maybe this should be further restricted to just join and ìnvite`?

Additionally some clients currently use key queries to enable encryption for a room. This might not be possible anymore with this change, leading to those rooms not supporting encryption anymore. Clients could change that to always enable encryption without checking if encryption is possible, but that likely will need a transition period?

Oh, I haven't heard of this before. 😮

This is before room creation when you already have a list of members to be invited and the client is checking upfront if you can encrypt to these users based on their published keys?


In all other cases, homeservers MAY ignore the queried MXIDs and omit them from
the response.

Servers MAY deny key queries over federation by responding with 403 and an error
code of `M_FORBIDDEN` on [`/_matrix/federation/v1/user/keys/query`].

## Potential issues

None.

## Alternatives

None.

## Security considerations

None.

## Unstable prefix

None.

## Dependencies

None.

[`/_matrix/client/v3/user_directory/search`]: https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3user_directorysearch
[`/_matrix/client/v3/profile/{userId}`]: https://spec.matrix.org/v1.13/client-server-api/#get_matrixclientv3profileuserid
[`/_matrix/federation/v1/query/profile`]: https://spec.matrix.org/v1.13/server-server-api/#get_matrixfederationv1queryprofile
[`/_matrix/client/v3/keys/query`]: https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3keysquery
[`/_matrix/federation/v1/user/keys/query`]: https://spec.matrix.org/v1.13/server-server-api/#post_matrixfederationv1userkeysquery