MSC3061: Sharing room keys for past messages

[uhoreg]

Rendered

Implementations:

• JS SDK
• Polyjuice Client Test
• Element iOS
• Element Android

FCP tickyboxes

[uhoreg]

Implemented by matrix-org/matrix-js-sdk#1640

[cvwright]

Implemented by matrix-org/matrix-js-sdk#1640

Is anyone working on this for matrix-ios-sdk?

[deepbluev7]

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?

[uhoreg]

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.

[deepbluev7]

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.

[dkasak]

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.

[deepbluev7]

So only the inviter will ever share keys?

[uhoreg]

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.

[uhoreg]

I've added some more words here. Hopefully it's clearer now.

[turt2live]

This MSC has completed FCP per the above comment.

[uhoreg]

Spec PR: matrix-org/matrix-spec#1655

[dkasak]

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/.

[richvdh]

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.