From ae8c3cfea7346f48bf57694281131a9ab75abcff Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 18 Jul 2023 22:29:16 -0400 Subject: [PATCH] initial version of MLS key backup proposal --- proposals/xxxx-mls-key-backup.md | 115 +++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 proposals/xxxx-mls-key-backup.md diff --git a/proposals/xxxx-mls-key-backup.md b/proposals/xxxx-mls-key-backup.md new file mode 100644 index 0000000000..0fca9fef84 --- /dev/null +++ b/proposals/xxxx-mls-key-backup.md @@ -0,0 +1,115 @@ +# MSCxxxx: MLS with key backup + +[MSC2883](https://github.com/matrix-org/matrix-spec-proposals/pull/2883) +defines how to use [Messaging Layer Security +(MLS)](https://messaginglayersecurity.rocks/) with [decentralisation +extensions](https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org) +for end-to-end encryption in Matrix. + +This MSC describes how to use MLS with Matrix's [server-side key +backups](https://spec.matrix.org/unstable/client-server-api/#server-side-key-backups) +so that users can read old messages after logging in to a new device. + +We only need to decrypt application messages and not handshake messages. That +is, we only need to decrypt MLS messages that encrypt Matrix events, and not +MLS messages that manage the MLS group. + +## Proposal + +A new backup algorithm is added, `m.dmls_backup.v1.aes-hmac-sha2`, to store MLS +group information. The existing key backup API stores data indexed by room ID +and by session ID. However MLS does not have a session ID. Instead, MLS, with +the decentralisation extensions, has epochs (which can be represented by a +number) and epoch creators. We thus encode the epoch and epoch creator +together to use as the session ID. + +TODO: The current implementation use `|`, where +`` is a decimal number, and `` is unpadded base64 of +`|` as the encoding. We should do something better. + +The `first_message_index` parameter in the key backup data has no meaning in +MLS, but the key backup API requires it; this parameter is set to 0. + +The session data, prior to encryption, is a JSON object with the following +properties: + +- `algorithm`: the string `m.dmls.v1.` where `` is + the string identifying the ciphersuite used for MLS +- `room_id`: the Matrix room ID +- `epoch`: an array of the form ... TODO +- `group_export`: an unpadded base64 encoding of the MLS group export as + defined below + +The session data is encrypted as described in +[MSC3270](https://github.com/matrix-org/matrix-spec-proposals/pull/3270), and +the `auth_data` is the same as described in the same MSC. + +### Group export + +The MLS group data is exported using [TLS presentation +language](https://www.rfc-editor.org/rfc/rfc8446#section-3), using the +definitions from MLS: + +```c +struct { + ProtocolVersion version = mls10; + CipherSuite ciphersuite; + GroupContext context; + opaque sender_data_secret; + opaque membership_key; + opaque confirmation_key; + opaque encryption_secret; + opaque interim_transcript_hash; + opaque epoch_authenticator; + KeyPackage key_packages; // or KeyPackageRef? + opaque authenticated_data; +} group_export; +``` + +TODO: determine how to handle key_packages, and RatchetTree extension if the +group supports that. Both can produce a lot of data in big groups, but there +can be a lot of duplication between backups, so we may be able to reduce total +storage. + +## Potential issues + +The current key backup API only allows writing to one backup version, so a user +cannot back up both Megolm and MLS keys. Possible solutions are: + +- change the backup API to allow one backup version per algorithm +- put MLS keys in the `m.megolm_backup.*` backup. Clients that do not support + MLS should ignore the MLS data since the keys do not fit the expected format, + and do not have the expected `algorithm` in the session data. +- store the MLS backup somewhere else. Part of the reason for having a + special API was so that the server could compare backed-up keys based on + cleartext data (e.g. first message index), and keep the "best" version. This + is not as necessary with MLS, and the group exports could be stored in a + simple key-value storage, such as per-room account data. However, the + account data system would not be suitable as it currently is, since storing + the keys in there would bloat `/sync` responses (in particular, the initial + sync). So this would require a change to account data to allow marking some + data so that it is not included in the `/sync`. + +## Security considerations + +For forward secrecy reasons, MLS disallows storing some of the information that +is included in the group export. This proposal conflicts with that +requirement, with the justification that users expect to be able to read old +messages, even on newly logged-in clients. The only way to be able to read old +encrypted messages is to store the decryption keys or to store the plaintext. +Key backup is an optional feature, so users can choose how they wish to balance +privacy or convenience. + +## Unstable prefix + +Until this MSC is accepted, clients should use +`org.matrix.mscxxxx.v0.aes-hmac-sha2` as the backup version. Note that the +session data contains an `algorithm` property giving the encryption algorithm +for the key. Until MSC2883 is accepted, the unstable identifier from that MSC +should be used as the algorithm name, rather than the stable identifier. + +## Dependencies + +This MSC builds on +[MSC2833](https://github.com/matrix-org/matrix-spec-proposals/pull/2883) (which +at the time of writing has not yet been accepted into the spec).