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
(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.
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:
- 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
- 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.
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.
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.