MSC3700: Deprecate plaintext sender key

[erikjohnston]

This deprecates the superfluous sender_key and device_id in a megolm message, e.g. an encrypted room event.

Rendered

Implementation: matrix-org/matrix-rust-sdk#481

Preview: https://pr3700--matrix-org-previews.netlify.app

[erikjohnston]

We should spell out what we mean by "trusted source" here

[erikjohnston]

I have done an implementation in the matrix-rust-sdk here: matrix-org/matrix-rust-sdk#481

[anoadragon453]

The positive review of matrix-org/matrix-rust-sdk#481 makes me cautiously optimistic about the implementation side of this. Though I would still like to see a review here from someone more intimately familiar with megolm before calling FCP.

[erikjohnston]

I think this is ready for FCP

[richvdh]

Session IDs are encoded ed25519 public keys

I think we should consider strengthening the wording in the spec to make this clear. Currently, https://spec.matrix.org/v1.2/client-server-api/#mmegolmv1aes-sha2 just says "outbound_group_session_id", without clarity on what exactly it is.

Buried within https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md we have "... the public part of K (acting as a session identifier) ...", but it's a bit hard to join the dots as things stand.

(Background: when I designed the megolm message format, the intention was that receiving clients would treat session_id as opaque, and they had no guarantee that it would be unique to a given device or even sender, hence the presence of the other fields.)

[richvdh]

seems good to me.

@mscbot fcp merge

[mscbot]

Team member @richvdh has proposed to merge this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[uhoreg]

This makes it sound like clients are not allowed to store sessions based on room ID or sender user ID, which I don't think is what is intended.

[erikjohnston]

Hmm, that is an interesting question actually. I think we don't want clients to ever lookup inbound sessions based on room ID or sender user ID, as they can be faked in exactly the same way as sender_key and device_id. Though I guess clients need to explicitly check that the sender user and room matches the session? I can make that more explicit.

[uhoreg]

At least for room ID, it's hard to fake since the event itself is tied to the room. (Also, your rust SDK PR stores by room ID and session ID.) Maybe it could say something like:

Clients should store and lookup sessions based purely on the session ID or based on the room ID and session ID. Clients must not store sessions based on the sender key or device ID.

?

[erikjohnston]

At least for room ID, it's hard to fake since the event itself is tied to the room.

The server could easily lie about the room ID for an event though. If we don't check the room ID matches the session room ID then it allows servers to forward encrypted events into other rooms.

---

I've updated the language to:

Clients must not store or lookup sessions using the sender key or device ID.

Client must continue to ensure that the event's sender and room ID fields match
those of the looked up session, e.g. by storing and looking up session using the
room ID and sender as well as the session ID.

[poljar]

The server could easily lie about the room ID for an event though. If we don't check the room ID matches the session room ID then it allows servers to forward encrypted events into other rooms.

It can't, the room ID is part of the encrypted payload as well[1].

[erikjohnston]

Hmm, so there are three places where we have a room ID? The event, the session and the encrypted payload? Presumably we still want to check that they all match?

[poljar]

Well, the event room id is a hint to find the right bucket, the session room id is just a hint into which bucket to put the session. The room id on the session also can't be replaced by the server.

The encrypted payload room id ensures that the server doesn't lie about the room id.

[erikjohnston]

Well, the event room id is a hint to find the right bucket, the session room id is just a hint into which bucket to put the session. The room id on the session also can't be replaced by the server.

Sure, but that relies on the client actually verifying the room IDs match. This can be done as you say by storing the sessions under the room ID they correspond to and then looking the session up via the room ID.

However, there is a risk here that clients will do the following:

1. Look up sessions solely via session ID.
2. Not check the room ID in the encrypted payload
3. Display the message in the room corresponding to the event's room ID.

At that point the client is vulnerable to the server lying about the event's room ID and making the client display the verified encrypted content into the wrong room.

A similar attack can happen with the sender.

The key issue here is that clients need to handle both encrypted and unecrypted events, so they're very likely to use the event's room ID and sender when rendering things in the UI, rather than any data in the encrypted payload or session. This makes it very important for clients to actually check that the user ID/senders and room IDs match.

[dkasak]

This makes it very important for clients to actually check that the user ID/senders and room IDs match.

Agreed. But what can we do to make this more prominent? The spec has some vague wording on this for room IDs:

We include the room ID in the payload, because otherwise the homeserver would be able to change the room a message was sent in.

But this is IMO neither clear nor noticeable enough. There is also this bogus paragraph:

As with Olm events, clients must confirm that the sender_key belongs to the user who sent the message. The same reasoning applies, but the sender ed25519 key has to be inferred from the keys.ed25519 property of the event which established the Megolm session.

This seems like a description of exactly what not to do. Clients should not look at sender_key as the server can easily spoof that (and is what's now being removed!). Instead, clients should record the (Curve25519) identity key and (Ed25519) fingerprint keys of the Olm device that initially shared a particular Megolm session.

---

I guess we need clear, actionable steps of what to do upon an encrypted room message receipt. Something like:

Upon receipt of an encrypted room message, do the following:

1. Record (Curve25519) identity key and (Ed25519) fingerprint key of the Olm device that initially sends the m.room_key for a particular message.
2. Check that the m.room.encrypted event's room ID matches the room_id field in the encrypted plaintext of the message. If not, fail.
   ...

If any of the above checks fail, the client must not display the message as a normal message. The client may display the message with a clear indication that it violates a required security property.

Ideally these rules would be in a differently coloured box to make it stand out from the rest of the text.

[BillCarsonFr]

The current behavior is to send to all your own devices with wildcard, but to the specific device_id of the sender. So this will need to change as it's not the current behavior. Notice that it will produce new to_device traffic

[turt2live]

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

[turt2live]

Merged 🎉

[MRAAGH]

This sounds like it might make decryption issues harder to debug; if there's no plaintext ID in the event, I won't even be able to check which client messages were sent from

[anoadragon453]

@MRAAGH Note that reduced ease of debugging is a known downside - it's listed at the bottom of the MSC. It was determined to be worth it for the increased privacy benefits (I can no longer tell you're sending messages from your phone at the moment).

I agree that this makes debugging old, undecryptable messages more difficult. But hopefully for recent conversations the involved parties will know which client sent what message.

[BillCarsonFr]

A late comment to note that this MSC is impacting MSC2399, as no_olm withheld codes are sent without session_id or room_id. This will make it impossible to relate a no_olm code to an unable to decrypt message.
We might need to modify MSC2399 so that no_olm codes are sent in the same way as other codes, removing the optimisation for sending them only once.

cc @poljar @uhoreg