From 673bcd436ad69ff01317417609796a666fd058a3 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Tue, 6 Sep 2022 14:32:25 +0100 Subject: [PATCH 1/9] MSC3884 --- proposals/3884-sliding-sync-e2ee.md | 77 +++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 proposals/3884-sliding-sync-e2ee.md diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md new file mode 100644 index 00000000000..c1c41b9a234 --- /dev/null +++ b/proposals/3884-sliding-sync-e2ee.md @@ -0,0 +1,77 @@ +# MSC3884: Sliding Sync Extension: E2EE + +This MSC is an extension to [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/pull/3575) +which includes support for end-to-end encrypted room fields in the `/sync` response. + +## Proposal + +MSC3575 does not include support for end-to-end encrypted rooms. This extension will add support for +end-to-end encrypted fields, specifically one-time keys, changed devices and fallback key types. + +The prosposal is to introduce a new extension called `e2ee` with the following request parameters: +```js +{ + "enabled": true, // sticky +} +``` +If `enabled` is `true`, then the sliding sync response MAY include the following response fields in +the `e2ee` extension response: +```json +{ + "device_one_time_keys_count": { + "signed_curve25519": 50 + }, + "device_lists: { + "changed": ["@alice:example.com"], + "left": ["@bob:example.com"] + }, + "device_unused_fallback_key_types": [ + "signed_curve25519" + ] +} +``` + +The semantics of these fields is exactly the same as the current `/sync` implementation, as implemented +in v1.3 of the Client-Server Specification. `device_lists` may be omitted if there are no users who +have changed/left. + +For sliding sync, an initial response will include all fields. When there are updates, only the +_changed_ fields are returned. That is to say, if `device_one_time_keys_count` has not changed between +requests, it will be omitted which means to use the previous value. This deviates from the current +`/sync` implementation which alwyas includes this field. Likewise for `device_unused_fallback_key_types`. + +## Potential issues + +It's unclear if `device_unused_fallback_key_types` and `device_one_time_keys_count` should always be +included or not, as this extension follows the same logic as v1.3 of the Specification which is not +clear on this. If it is always included, this adds extra bytes and therefore consumes needless +bandwidth. In practice, Synapse _always_ includes these fields, when this is probably not needed. +Changing this behaviour may break clients which expect these fields to always exist. + +## Alternatives + +The alternative is to not include this extension at all, making it impossible to include reliable +E2EE support in Sliding Sync. As this extension is opt-in, as all Sliding Sync extensions are, this +feels undesirable to not provide this extension. + +## Security considerations + +No additional security considerations beyond what the current `/sync` implementation provides. + +## Unstable prefix + +No unstable prefix as Sliding Sync is still in review. To enable this extension, just add this to +your request JSON: +```js +{ + "extensions: { + "e2ee": { + "enabled": true + } + } +} +``` + +## Dependencies + +This MSC builds on MSC3575, which at the time of writing has not yet been accepted into the spec. From d7ee2d53044be5030c59243a04bf5b6798ed577c Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Tue, 6 Sep 2022 14:44:28 +0100 Subject: [PATCH 2/9] Typo --- proposals/3884-sliding-sync-e2ee.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index c1c41b9a234..4974f82851c 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -38,12 +38,12 @@ have changed/left. For sliding sync, an initial response will include all fields. When there are updates, only the _changed_ fields are returned. That is to say, if `device_one_time_keys_count` has not changed between requests, it will be omitted which means to use the previous value. This deviates from the current -`/sync` implementation which alwyas includes this field. Likewise for `device_unused_fallback_key_types`. +`/sync` implementation which always includes this field. Likewise for `device_unused_fallback_key_types`. ## Potential issues It's unclear if `device_unused_fallback_key_types` and `device_one_time_keys_count` should always be -included or not, as this extension follows the same logic as v1.3 of the Specification which is not +included or not, as this extension deviates from the logic as v1.3 of the Specification which is not clear on this. If it is always included, this adds extra bytes and therefore consumes needless bandwidth. In practice, Synapse _always_ includes these fields, when this is probably not needed. Changing this behaviour may break clients which expect these fields to always exist. From ccc544535d251d2b65c04b2a63fec325a3f3cec0 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Tue, 6 Sep 2022 14:46:53 +0100 Subject: [PATCH 3/9] More typos --- proposals/3884-sliding-sync-e2ee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index 4974f82851c..d12251b30f5 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -21,7 +21,7 @@ the `e2ee` extension response: "device_one_time_keys_count": { "signed_curve25519": 50 }, - "device_lists: { + "device_lists": { "changed": ["@alice:example.com"], "left": ["@bob:example.com"] }, From 40f4228c3d8ee5fdb869cbe5e52f510c836097a8 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Tue, 6 Sep 2022 16:37:01 +0100 Subject: [PATCH 4/9] Update 3884-sliding-sync-e2ee.md grammar --- proposals/3884-sliding-sync-e2ee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index d12251b30f5..f48abe80c45 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -51,7 +51,7 @@ Changing this behaviour may break clients which expect these fields to always ex ## Alternatives The alternative is to not include this extension at all, making it impossible to include reliable -E2EE support in Sliding Sync. As this extension is opt-in, as all Sliding Sync extensions are, this +E2EE support in Sliding Sync. As this extension is opt-in, as all Sliding Sync extensions are, it feels undesirable to not provide this extension. ## Security considerations From 47720696704e6036c5e7853f55f8e83b10baf561 Mon Sep 17 00:00:00 2001 From: kegsay Date: Wed, 7 Sep 2022 10:07:15 +0100 Subject: [PATCH 5/9] Update 3884-sliding-sync-e2ee.md --- proposals/3884-sliding-sync-e2ee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index f48abe80c45..9d06cbcd307 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -64,7 +64,7 @@ No unstable prefix as Sliding Sync is still in review. To enable this extension, your request JSON: ```js { - "extensions: { + "extensions": { "e2ee": { "enabled": true } From 07b773e0417c3b41700d6ea0cfc5b37923305f21 Mon Sep 17 00:00:00 2001 From: kegsay Date: Thu, 22 Dec 2022 14:39:06 +0000 Subject: [PATCH 6/9] Update 3884-sliding-sync-e2ee.md --- proposals/3884-sliding-sync-e2ee.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index 9d06cbcd307..84bf198ef23 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -31,6 +31,9 @@ the `e2ee` extension response: } ``` +All keys are optional and clients MUST check if they exist prior to use. If there are zero changes to +every field then the server MAY omit sending back an `e2ee` extension entirely. + The semantics of these fields is exactly the same as the current `/sync` implementation, as implemented in v1.3 of the Client-Server Specification. `device_lists` may be omitted if there are no users who have changed/left. From b8e53003aeb399d6171b630f99ac229279ad1c58 Mon Sep 17 00:00:00 2001 From: David Robertson Date: Mon, 3 Apr 2023 15:47:27 +0100 Subject: [PATCH 7/9] E2EE cannot be list- or room-scoped --- proposals/3884-sliding-sync-e2ee.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index 84bf198ef23..4bc519e0e66 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -9,11 +9,15 @@ MSC3575 does not include support for end-to-end encrypted rooms. This extension end-to-end encrypted fields, specifically one-time keys, changed devices and fallback key types. The prosposal is to introduce a new extension called `e2ee` with the following request parameters: -```js +```json5 { "enabled": true, // sticky } ``` + +_Note: This extension ignores the core `lists` and `rooms` parameters to extensions, because none of the +data returned by this extension is scoped to a particular room._ + If `enabled` is `true`, then the sliding sync response MAY include the following response fields in the `e2ee` extension response: ```json @@ -65,11 +69,11 @@ No additional security considerations beyond what the current `/sync` implementa No unstable prefix as Sliding Sync is still in review. To enable this extension, just add this to your request JSON: -```js +```json { "extensions": { "e2ee": { - "enabled": true + "enabled": true, } } } From bb7a74e64e9c2dcab769d26e06279d2d6322e243 Mon Sep 17 00:00:00 2001 From: David Robertson Date: Tue, 30 May 2023 16:03:28 +0100 Subject: [PATCH 8/9] Don't use the E2EE extension across multiple conns --- proposals/3884-sliding-sync-e2ee.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index 4bc519e0e66..0987bf81eb3 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -55,6 +55,16 @@ clear on this. If it is always included, this adds extra bytes and therefore con bandwidth. In practice, Synapse _always_ includes these fields, when this is probably not needed. Changing this behaviour may break clients which expect these fields to always exist. +### Concurrent connections + +The sliding sync protocol allows multiple concurrent connections disambiguated +by a `conn_id`: see "Concurrent connections" of [MSC3575]( + https://github.com/matrix-org/matrix-spec-proposals/pull/3575 +). Clients using multiple concurrent connections MUST enable the E2EE +extension on at most one connection. Using the E2EE extension on multiple +concurrent connections is not supported; doing so risks data loss and E2EE +messaging failures. + ## Alternatives The alternative is to not include this extension at all, making it impossible to include reliable @@ -69,7 +79,7 @@ No additional security considerations beyond what the current `/sync` implementa No unstable prefix as Sliding Sync is still in review. To enable this extension, just add this to your request JSON: -```json +```json5 { "extensions": { "e2ee": { From 5ff5682b114354577dad775dd2d9b653cf531f0f Mon Sep 17 00:00:00 2001 From: kegsay <7190048+kegsay@users.noreply.github.com> Date: Thu, 4 Jan 2024 17:19:59 +0000 Subject: [PATCH 9/9] Update 3884-sliding-sync-e2ee.md --- proposals/3884-sliding-sync-e2ee.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proposals/3884-sliding-sync-e2ee.md b/proposals/3884-sliding-sync-e2ee.md index 0987bf81eb3..32d58e184b7 100644 --- a/proposals/3884-sliding-sync-e2ee.md +++ b/proposals/3884-sliding-sync-e2ee.md @@ -47,6 +47,13 @@ _changed_ fields are returned. That is to say, if `device_one_time_keys_count` h requests, it will be omitted which means to use the previous value. This deviates from the current `/sync` implementation which always includes this field. Likewise for `device_unused_fallback_key_types`. +Particular care must be taken when a fallback key is used, as this will cause the response to be: +```json +"device_unused_fallback_key_types": [] +``` +which is not the same as the field being omitted/null. The empty array means the key was used. Omitted +fields means no changes. + ## Potential issues It's unclear if `device_unused_fallback_key_types` and `device_one_time_keys_count` should always be