MSC4268: Sharing room keys for past messages

[richvdh]

A proposal for sharing the keys to existing room messages when inviting someone to a room.

This reintroduces the functionality previously proposed in MSC3061.

Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Cryptography team.

The functionality discussed here is implemented in current versions of Element Web and Element X.

Rendered

MSC checklist
FCP tickyboxes

[ara4n]

My two main concerns on this MSC are:

• Without the ability to delete key bundles once they've been consumed by the invited user, we accumulate encrypted key material in a way which is tantamount to harvest-now-decrypt-later attacks. However, given MSC4425 (or other ephemeral MSCs) are on the radar, I'm (just about) happy to for this to progress on the understanding that we follow up afterwards rapidly with MSC4425 or similar.

• In terms of use experience, it's really not obvious to me that the common case should be to share all possible keys with an invited user. Sometimes this will be important (e.g. knowledge transfer to a new user joining a team/org) - but sometimes it will be very undesirable even if the room has shared history viz, particularly if the history viz been changed back and forth over time. I suspect that an approach similar to the WhatsApp idiom of "how much history do you want to share with the new user? nothing? 1 msg? 100 msgs? everything?" might help with this. However: this is a client UX question and is already supported by the MSC.

So, neither of these points end up being blocking, although both make me quite uncomfortable with the proposal. I'll checkbox it to proceed, but please can we track these concerns on the Element crypto-team agenda so they're not lost.

[richvdh]

• Without the ability to delete key bundles once they've been consumed by the invited user, we accumulate encrypted key material in a way which is tantamount to harvest-now-decrypt-later attacks. However, given MSC4425 (or other ephemeral MSCs) are on the radar, I'm (just about) happy to for this to progress on the understanding that we follow up afterwards rapidly with MSC4425 or similar.

This is already tracked at matrix-org/matrix-rust-sdk#5113, though I would say that we'd need to deprioritise some other scheduled work for any followup to be rapid.

In terms of use experience, it's really not obvious to me that the common case should be to share all possible keys with an invited user.

My inclination on this is to deliver the implementation we have and see what feedback we get.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[richvdh]

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

[turt2live]

Merged 🎉