Sharing room keys for past messages on invite (MSC3061, or its successors)

[dkasak]

When you are invited to an encrypted room with the "Who can read history" option set to "members only (since the point in time of selecting this option)" (i.e. m.room.history_visibility = shared), you should be able to read old messages.

Currently, old messages are displayed as "You don't have access to this message".

Previously, MSC3061 provided a solution, but it was found to be impractical.

This issue includes creating a new MSC for a more practical solution, and implementing it on Element clients.

Proposed solution

Our current plan (internal notes, comparing other solutions) is closely based on MSC3061, but rather than sending the message keys as to-device messages, put them in an encrypted media blob, and then send the keys to that in a to-device message.

In other words, when you invite a user to an encrypted room then (provided they do not have an identity pinning violation):

• Build a "bundle" of keys for that room, and upload it as an encrypted blob to the server.
  • Initially we can just use an encrypted media file for the blob; however that conflicts with MSC3911, and limits flexibility in terms of deleting the file once its purpose is served and adding more data to it incrementally. It's likely we'll want dedicated APIs for this later.
• Before sending the invite event, send to-device messages to all the recipient's verified devices telling them where they can get the encrypted key bundle, and including the decryption keys. (Likely this will look much like the current encrypted attachment format, with potential improvements)
• As a recipient, we should only accept key bundles from verified devices belonging to users who do not have a verification violation.

We'll also need UI which tells the recipient who sent the keys ("history as presented by Bob", or so), since there is no way for that recipient to know that the inviter isn't lying.

Another important bit of UI is to make it clear to all members of history_visibility: shared rooms that messages they send now may be shared with future room members. Our experience is that different users have wildly different expectations in this respect.

This obviously won't solve access to history when joining rooms without an invite; however our favoured solutions to that (#750) involve similar mechanisms, so this will provide useful groundwork.

Task list

We will start by building a prototype.

Later work is: #2829

Later work may include:

• Refinement

  • write an MSC
  • Download all keys from backup before sending key bundle
  • User feedback while building key bundles: make "create invite" observable so we have a progress bar or similar
  • UX for telling users your history may be shared
  • What if the room history setting changed in the past?
    • We need to know what the history visibility setting was when that message was sent -- otherwise we could end up sharing keys for messages that the sender assumed would remain confidential.
    • We can't trust the server to tell us this; instead, we need the sender to annotate message keys (or messages, maybe?) to tell us. TODO: add this information to the m.room_key events.
    • MSC3061 solved this with the shared_history property, but that means we will never share history from clients that do not implement the history sharing property.
    • We could make shared_history default to true (ie, make history-sharing opt-out) at least at first, but it's not ideal. Also, it'll still be confusing behaviour if a paranoid user/client sets this to false everywhere.
    • (Thought from @richvdh: maybe we can solve this with (a) UX messaging to the inviter saying "Some keys could not be shared to the invitee due to restrictions set by the sender; (b) metadata in the key bundle saying "yeah sorry we can't share the keys to this session with you"; (c) messaging in the invitee client explaining the situation)
  • What if the sender doesn't have all the keys?
  • UI design+impl in EW+EX for main flow: sending and receiving

• Handle Provenance of keys

  • Record who sent us these keys
  • Display who sent them in the UI
  • Ensure that this information is recorded in authenticated backup

• Deleting the files or using a new API

Tasks

• Encrypted history sharing: in m.room_key messages, mark whether the room key can be reshared #2720
• Prototype encrypted room history sharing #2685

Relevant client-specific issues

• Inviting a user to an E2EE room does not share keys for history with them, causing UISIs everywhere. element-x-ios#1496
• Historical room key sharing (key share on invite) element-web#26867

Old description

• Add Flag to disable/enable it in crypto config
• UX | Add an info text in the invite dialog stating that history will be shared
• Implement on other platforms.
  • Sharing room keys for past messages element-android#4153
  • Sharing room keys for past messages element-ios#4947
  • Implement MSC3061: Sharing room keys for past messages  matrix-org/matrix-rust-sdk#580
  • Share keys for historical messages when inviting users to encrypted rooms matrix-org/matrix-react-sdk#5763
  • Inviting a user to an E2EE room does not share keys for history with them, causing UISIs everywhere. element-x-ios#1496
• Historical room key sharing (key share on invite) element-web#26867

[BillCarsonFr]

SCOPE UPDATE

There are some scalability issues with sending the keys for the full history, as well as several edge cases. We don't want to fix all of them on existing SDKs (mobile, web).
The Rust SDK implementation should be complete.

So for existing SDKS the main goal is to give the new joiner the immediate context on the room to know why he was invited, so basically the recent histoty not full history.

^ DEPRECATED SINCE LAST UPDATE