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

Preview Give feedback

1. Prototype encrypted room history sharing #2685
   0 of 12
   T-Story Team: Crypto +2

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.

[benparsons]

Do we think implementation of MSC3061 should include web? element-hq/element-web#22999 is a web UI task for room history key sharing that is currently biting a customer fairly badly. If we could include this task here it would be helpful.

[richvdh]

Do we think implementation of MSC3061 should include web? vector-im/element-web#22999 is a web UI task for room history key sharing that is currently biting a customer fairly badly. If we could include this task here it would be helpful.

I'm reasonably sure this is already implemented on web. AFAICT element-hq/element-web#22999 is just a bug, not a missing implementation.

EDIT 2024-06-13: this is no longer true, because the Rust crypto stack doesn't implement it; tracked at element-hq/element-web#26867

[thoraj]

We consider this feature important. Without it using Matrix for collaboration in a business setting is cumbersome.
E.g when:

• Bringing new team members to a project which is discussed in a room
• Have a co-worker cover your tasks when on vacation
• ++

What needs to happen to get this MSC moving again, so it can be merged, and find its way to clients and servers?

[jeudesprits]

I agree with what has been said above. We also chose Matrix but didn’t pay much attention to this issue at the beginning, and now we really need this feature. It would be great to hear some timelines, if possible.

[thoraj]

A guesstimate for when the security disclosure will be made would be nice. Depending on the potential attack vector the risks may be mitigated or accepted.

Without the disclosure we don't know.

[mpeter50]

I agree that this feature is very important, but @thoraj , did you intend your last comment to be sent here? If so, what kind of security disclosure do you mean? As I understand, a vulnerability was not a topic here.

[thoraj]

@mpeter50 Sorry for not providing context.

My reference to a disclosure is based on a comment made in #e2e:matrix.org today. Apparently the MSC is blocked awaiting a security disclosure and having the issue resolved.

[dkasak]

We're working on this now, so the disclosure should come in the next couple of weeks.

[thoraj]

@dkasak Any updates for this?

We are receiving complaints about this being flaky for our customer, and we are curious to know what the issue/disclosure is about, and how we can address this?

[dkasak]

Yes, sorry, I wanted to post an update but failed to find this particular issue.

The reason this was blocked was disclosed today in https://matrix.org/blog/2024/10/security-disclosure-matrix-js-sdk-and-matrix-react-sdk/ and the associated advisories. The plan forward is outlined in this section.

[richvdh]

I've updated the description of this issue to reflect our current plans in this area.

[thoraj]

Very happy to see this progress, and that there are very concrete plans now 👍New members getting room history in encrypted rooms is indeed an important feature.

I know it is not in scope atm, but I'm also wondering if the proposed exfiltration of keys using a blob, in the future could be utilized to provide keys for indexing room messages (for search purposes).

[IntelligentesTierMaulApollo13]

Maybe I missed something while digging through the whole history of this topic, so I apologize right at the beginning:

From what I've read, my understanding is that in order to access history in encrypted rooms in the future, the inviting party must verify one of the invited party's sessions (so that the keys are actually transmitted). Now, I'm thinking of the case where a new user joins the server and needs access to, say, 30 rooms, each of which has a different moderator (and only that moderator is allowed to invite new members to the room). As I understand it, in this case the new user would have to verify their session with each of these room moderators.

Is there any shortcut or way to automate this for environments where there are many such rooms? (I know that automating this potentially lowers security as it is then easier for an attacker to gain access to a verified session...)

Another option I thought about is if it was possible to define a "trusted introducer" (to reuse the term from GnuPG) or a WoT-approach, but I assume there is also nothing similar, right?

[richvdh]

From what I've read, my understanding is that in order to access history in encrypted rooms in the future, the inviting party must verify one of the invited party's sessions (so that the keys are actually transmitted).

This is incorrect. Sorry, it's not very clear from the description at the top of this issue -- the description assumes familiarity with terminology that we use internally. So, I'll try to spell it out explicitly.

The plan relies on cross-signing by user identities and a TOFU for the identities themselves.

Suppose Alice wants to invite Bob to a room. When Alice first meets Bob, her client records Bob's public cryptographic identity. Now, when Alice sends the invite to the new room, her client will send the details of the key bundle to any of Bob's devices which Bob has verified, provided Bob's cryptographic identity hasn't changed since Alice first saw Bob. We do not require that Alice explicitly verify Bob or any of his devices.

This is consistent with our plans for encrypted messaging in general; see MSC4153.

[IntelligentesTierMaulApollo13]

... a TOFU for the identities themselves.

It seems that this is what I was missing. Thank you for your answer!

Maybe one thing which made it easier for me to get confused is the behavior of a setting I have in my Element Web client that is labeled Never send encrypted messages to unverified sessions in this room from this session. This actually forces me to explicitly verify at least one of the receiving user's sessions. So, when you were talking about verification I assumed the same meaning.