MSC3061: Sharing room keys for past messages #3061
Conversation
uhoreg
changed the title
|
Implemented by matrix-org/matrix-js-sdk#1640 |
After discussion with Product, we're ready to enable this key sharing work from #5763 (based on matrix-org/matrix-spec-proposals#3061).
turt2live
added
the
needs-implementation
Is anyone working on this for matrix-ios-sdk? |
| ## Security considerations | ||
|
|
||
| Clients should still ensure that keys are only shared with authorized users and | ||
| devices. |
There was a problem hiding this comment.
How does this work? How does the client know, that a user should be in the room and wasn't maliciously added by the homeserver? Even if you set a room to shared history, you probably only want members to read the history, that you accepted as having been allowed into the room. Considering the end aspect in e2ee, we want the client to approve of a member having joined the room, before sharing history. We don't want to automatically share keys with anyone, who joins the room, because the server could for a short time "fake" a user in the room and as such get access to all the history and then make the user disappear again. Then encrypting the room would be useless. Should we require prompting the user once before sharing past history with a new user in the room?
There was a problem hiding this comment.
This is sort of a generic "make sure that you don't accidentally over-share when you implement this". In this case, clients only share the keys with users that the client invites, so it's decided that the user should be authorized. For determining which devices are authorized, in general, the client should probably just do what it normally does for determining which devices to send keys to.
There was a problem hiding this comment.
I think this is a really scary trap, because a client dev might forget, that the servers device list and member list isn't really that trustworthy. We somewhat get around that by warning for unverified devices, when sending a message, but that will never work for sharing past message keys.
There was a problem hiding this comment.
The proper solution here is to base the decision whether to share on the trust state of the user we're inviting.
If the invited user is untrusted (in cross-signing terms), the client should at least display a warning along with a list of devices that would get the keys. This would allow the inviter to at least review the list and consciously proceed with the action if they want to do so.
If the invited user is trusted, but some of their devices are not verified yet, the client should again display a warning with a list of those devices, again asking whether to proceed.
If the user is trusted and all of their devices are verified, then no warning is necessary.
There was a problem hiding this comment.
So only the inviter will ever share keys?
There was a problem hiding this comment.
It doesn't have to be just the inviter who shares keys; others can share keys as well, but it's up to them to ensure that they do so securely. Spec-wise, we try to avoid telling clients exactly how to handle keys, as different clients may wish to make different tradeoffs. But I will add a comment about checking device trust before sharing.
There was a problem hiding this comment.
I've added some more words here. Hopefully it's clearer now.
turt2live
added
the
final-comment-period
|
This MSC has completed FCP per the above comment. |
turt2live
added
finished-final-comment-period
and removed
final-comment-period
turt2live
added
spec-pr-missing
* initial version * use MSC number * address comments from review * fix list * fix markdown Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --------- Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
Spec PR: matrix-org/matrix-spec#1655 |
uhoreg
added
spec-pr-in-review
|
The spec text PR for this MSC was (in)famously blocked on a security concern. This concern is now disclosed at https://matrix.org/blog/2024/10/security-disclosure-matrix-js-sdk-and-matrix-react-sdk/. |
|
Following the above disclosure, the Spec Core team have decided to revert the merging of this proposal. A future proposal is welcome to use this one as a basis. |
This reverts commit 6a3ab1d. Per https://matrix.org/blog/2024/10/security-disclosure-matrix-js-sdk-and-matrix-react-sdk/ and #3061 (comment), we are removing the merged status of this PR.
richvdh
added
abandoned
|
Removed from matrix-js-sdk in https://github.com/matrix-org/matrix-js-sdk/releases/tag/v34.8.0 |
Rendered
Implementations:
FCP tickyboxes