Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-26 19:08:38 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Expand on why we can't trust dirty homeservers

Browse source
This commit is contained in:
Andrew Morgan 2019-07-23 13:28:42 +01:00
parent 577021f12b
commit b26a9ed1fd
1 changed files with 19 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
proposals/2134-identity-hash-lookup.md
View file

@ -234,10 +234,6 @@ of a stream cipher.
## Other considered solutions
Ideally identity servers would never receive plain-text addresses, however it
is necessary for the identity server to send email/sms messages during a
bind, as it cannot trust a homeserver to do so as the homeserver may be lying.
Bloom filters are an alternative method of providing private contact discovery.
However, they do not scale well due to requiring clients to download a large
filter that needs updating every time a new bind is made. Further considered
@ -257,15 +253,27 @@ what a client/identity-server interaction would look like are documented [in
this Github
comment](https://github.com/matrix-org/matrix-doc/pull/2134#discussion_r298691748).
Additionally, a radical model was also considered where the first portion of
the above scheme was done with an identity server, and the second would be done
with various homeservers who originally reported the 3PID to the identity
server. While interesting and a more decentralised model, some attacks are
still possible if the identity server is running an evil homeserver which it
can direct the client to send its hashes to. Discussion on this matter has
taken place in the MSC-specific room [starting at this
A radical model was also considered where the first portion of the
k-anonyminity scheme was done with an identity server, and the second would
be done with various homeservers who originally reported the 3PID to the
identity server. While interesting and a more decentralised model, some
attacks are still possible if the identity server is running an evil
homeserver which it can direct the client to send its hashes to. Discussion
on this matter has taken place in the MSC-specific room [starting at this
message](https://matrix.to/#/!LlraCeVuFgMaxvRySN:amorgan.xyz/$4wzTSsspbLVa6Lx5cBq6toh6P3TY3YnoxALZuO8n9gk?via=amorgan.xyz&via=matrix.org&via=matrix.vgorcum.com).
Ideally identity servers would never receive plain-text addresses, just
storing and receiving hash values instead. However, it is necessary for the
identity server to have plain-text addresses during a
[bind](https://matrix.org/docs/spec/identity_service/r0.2.1#post-matrix-identity-api-v1-3pid-bind)
call, in order to send a verification email or sms message. It is not
feasible to defer this job to a homeserver, as the identity server cannot
trust that the homeserver has actually performed verification. Thus it may
not be possible to prevent plain-text 3PIDs of registered Matrix users from
being sent to the identity server at least once. Yet, we can still do our
best by coming up with creative ways to prevent non-matrix user 3PIDs from
leaking to the identity server, when they're sent in a lookup.
## Conclusion
This proposal outlines a simple method to stop bulk collection of user's