MSC4263: Preventing MXID enumeration via key queries #4263
Conversation
Johennes
force-pushed
the
feature/prevent-mxid-enumeration-via-key-queries
branch
from
3175c4e to
df66664
Compare
Johennes
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am a Systems Architect at gematik, Software Engineer at Unomed, Matrix community member and former Element employee. This proposal was written and published with my gematik hat on.