From b26a9ed1fd7f847a701028efcba55f6aff82d1c3 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 23 Jul 2019 13:28:42 +0100 Subject: [PATCH] Expand on why we can't trust dirty homeservers --- proposals/2134-identity-hash-lookup.md | 30 ++++++++++++++++---------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/proposals/2134-identity-hash-lookup.md b/proposals/2134-identity-hash-lookup.md index 8db758dc..5bd4889a 100644 --- a/proposals/2134-identity-hash-lookup.md +++ b/proposals/2134-identity-hash-lookup.md @@ -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