MSC3700: Deprecate plaintext sender key

proposals/3700-deprecate-sender-key.md

@@ -0,0 +1,76 @@
+# 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.