77 lines
3.7 KiB
Markdown
77 lines
3.7 KiB
Markdown
# MSC3700: Deprecate plaintext sender_key
|
||
|
||
This MSC proposes to deprecate superfluous fields from the plaintext event
|
||
content of encrypted events, increasing privacy and enhancing security.
|
||
|
||
An encrypted message that uses an algorithm of
|
||
[`m.megolm.v1.aes-sha2`](https://spec.matrix.org/v1.2/client-server-api/#mmegolmv1aes-sha2)
|
||
(such as an `m.room.encrypted` event) contains the following plain text keys in
|
||
its contents: `algorithm`, `session_id`, `sender_key` and `device_id`. Both the
|
||
`algorithm` and `session_id` are required for clients to be able to decrypt the
|
||
ciphertext: the algorithm explains how to decrypt and the session ID says which
|
||
session to use to decrypt the ciphertext.
|
||
|
||
The `sender_key` and `device_id` are currently used by clients to store and
|
||
lookup sessions in addition to the `session_id`, however the `session_id` is
|
||
globally unique and so no disambiguation using `sender_key` or `device_id` is
|
||
needed.
|
||
|
||
Session IDs are encoded ed25519 public keys. In particular, the session ID is
|
||
the public part of the key used to sign the session when it is shared.
|
||
|
||
## Proposal
|
||
|
||
The `sender_key` and `device_id` in `m.megolm.v1.aes-sha2` message contents are
|
||
deprecated. Clients must ignore those fields when processing events, but should
|
||
still include the fields when generating events to maintain backwards
|
||
compatibility. At a future time the fields will stop being included.
|
||
|
||
Similarly, the `sender_key` field in `m.room_key_request` to-device messages is
|
||
deprecated. Clients must ignore the field when processing the request, but
|
||
should still include it when generating *if* there is a `sender_key` field in
|
||
the event we're requesting keys for.
|
||
|
||
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.
|
||
|
||
When updating an existing session key, clients must ensure:
|
||
1. that the updated session data comes from a trusted source, e.g. either the
|
||
session data has a) a valid signature, or b) comes from the user’s session
|
||
key backup; and
|
||
2. that the new session key has a lower message index than the existing session
|
||
key.
|
||
|
||
When clients receive an encrypted event with an unknown session they will need
|
||
to send a key request to all clients, rather than the device specified by
|
||
`sender_key` and `device_id`. This is the current behaviour used by Element
|
||
clients.
|
||
|
||
### Benefits
|
||
|
||
There are two main benefits of removing the `sender_key` and `device_id`:
|
||
enhanced privacy and better security.
|
||
|
||
Including these extra fields leaks which device was used to send the message,
|
||
and so removing them has an obvious privacy benefit.
|
||
|
||
On the security side, these fields are untrusted as: a malicious server (or
|
||
other man-in-the-middle (MITM) attacker) can change these values; and other
|
||
devices/users can simply lie about these values.
|
||
|
||
Currently, clients therefore need to take care to only use these values to look
|
||
up the session. If the client needs to know the associated `sender_key` they
|
||
must use the identity key of the Olm session that was used to send them the
|
||
Megolm session data, and not the `sender_key` in the event contents.
|
||
|
||
This is an obvious footgun, and therefore removing/ignoring these untrusted
|
||
fields reduces the risk of security bugs being introduced.
|
||
|
||
## Potential issues
|
||
Removing the `sender_key` and `device_id` means that clients don’t know which
|
||
remote device to ask for the session key if they don’t already have it. Instead,
|
||
clients will need to send a key request to all devices of the event sender. This
|
||
will also reduce the information available when debugging encryption issues.
|