From b535226d407b28709c8d126ef6852f3bb9344c10 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 13 Nov 2018 22:00:42 -0500 Subject: [PATCH 01/10] initial work on documenting olm unwedging --- proposals/xxxx-olm_unwedging.md | 45 +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 proposals/xxxx-olm_unwedging.md diff --git a/proposals/xxxx-olm_unwedging.md b/proposals/xxxx-olm_unwedging.md new file mode 100644 index 000000000..60f45fe12 --- /dev/null +++ b/proposals/xxxx-olm_unwedging.md @@ -0,0 +1,45 @@ +# Olm unwedging + +Olm sessions sometimes get out of sync, resulting in undecryptable messages. +This proposal documents a method for devices to create a new session to replace +the broken session. + +## Proposal + +When a device receives an olm-encrypted message that it cannot decrypt, it +should assume that the olm session has become corrupted and create a new olm +session to replace it. It should then send a dummy message, using that +session, to the other party in order to inform them of the new session. To +send a dummy message, clients may send an event with type `m.dummy`, and with +empty contents. + +If the corrupted session has already been replaced, the receiving device should +do nothing, under the assumption that the message from the corrupted session +was sent before the sender was informed of the replacement session, in order to +avoid creating too many extra sessions. + +The spec currently says, "If a client has multiple sessions established with +another device, it should use the session from which it last received a +message." (the last paragraph of the [`m.olm.v1.curve25519-aes-sha2` +section](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-olm-v1-curve25519-aes-sha2)). +When comparing the time of the last received message for each session, the +client should consider only consider messages that were successfully decrypted, +and for sessions that have never received a message, it should use the creation +time of the session. The spec will be changed to read: + +> If a client has multiple sessions established with another device, it should +> use the session from which it last received and successfully decrypted a +> message. For these purposes, a session that has not received any messages +> should consider its creation time to be the time that it last received a +> message. + +## Tradeoffs + +## Potential issues + +## Security considerations + +## Conclusion + +This proposal outlines how wedged olm sessions can be replaced by a new +session. From d0bfdc13af8b4b8e5bba695c6f6bb3a2f6d7d275 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 13 Nov 2018 22:03:07 -0500 Subject: [PATCH 02/10] rename to match MSC number --- proposals/{xxxx-olm_unwedging.md => 1719-olm_unwedging.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{xxxx-olm_unwedging.md => 1719-olm_unwedging.md} (100%) diff --git a/proposals/xxxx-olm_unwedging.md b/proposals/1719-olm_unwedging.md similarity index 100% rename from proposals/xxxx-olm_unwedging.md rename to proposals/1719-olm_unwedging.md From 495df02da6efb5d821fad69abb4fb66600db20b4 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 14 Nov 2018 10:19:11 -0500 Subject: [PATCH 03/10] we don't actually know which session got stuck, so rate-limit by device --- proposals/1719-olm_unwedging.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 60f45fe12..13c4ea4b4 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -13,10 +13,11 @@ session, to the other party in order to inform them of the new session. To send a dummy message, clients may send an event with type `m.dummy`, and with empty contents. -If the corrupted session has already been replaced, the receiving device should -do nothing, under the assumption that the message from the corrupted session -was sent before the sender was informed of the replacement session, in order to -avoid creating too many extra sessions. +In order to avoid creating too many extra sessions, a client should rate-limit +the number of new sessions it creates per device that it receives a message +from; the client should not create a new session with another device if it has +already created one for that given device in the past 1 hour. (TODO: is 1 hour +the right amount of time?) The spec currently says, "If a client has multiple sessions established with another device, it should use the session from which it last received a From 2b5805255564bb80a63c73dd977b487c67c9007c Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 14 Nov 2018 10:28:26 -0500 Subject: [PATCH 04/10] add note about re-requesting megolm keys --- proposals/1719-olm_unwedging.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 13c4ea4b4..e696c1e2f 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -19,6 +19,12 @@ from; the client should not create a new session with another device if it has already created one for that given device in the past 1 hour. (TODO: is 1 hour the right amount of time?) +Clients may wish to ask the sender of the undecryptable messages to re-send the +message. For exampe, if the undecryptable message was a megolm session, then +the client can send an +[`m.room_key_request`](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-room-key-request) +message to request that the sender re-send the key. + The spec currently says, "If a client has multiple sessions established with another device, it should use the session from which it last received a message." (the last paragraph of the [`m.olm.v1.curve25519-aes-sha2` From 77050062601cad901623660de151081608fb5ca3 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 22 May 2019 12:43:43 -0400 Subject: [PATCH 05/10] 1 hour seems to be fine --- proposals/1719-olm_unwedging.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index e696c1e2f..50b6f0e61 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -16,8 +16,7 @@ empty contents. In order to avoid creating too many extra sessions, a client should rate-limit the number of new sessions it creates per device that it receives a message from; the client should not create a new session with another device if it has -already created one for that given device in the past 1 hour. (TODO: is 1 hour -the right amount of time?) +already created one for that given device in the past 1 hour. Clients may wish to ask the sender of the undecryptable messages to re-send the message. For exampe, if the undecryptable message was a megolm session, then From d39baba21b64c0dfe3b57e2bbbe8b9609fb69f2d Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 22 May 2019 12:44:04 -0400 Subject: [PATCH 06/10] add a security note --- proposals/1719-olm_unwedging.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 50b6f0e61..3e0ce35da 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -45,6 +45,10 @@ time of the session. The spec will be changed to read: ## Security considerations +An attacker could use this to create a new session on a device that they are +able to read. However, this would require the attacker to have compromised the +device's keys. + ## Conclusion This proposal outlines how wedged olm sessions can be replaced by a new From dd74baa5d0fb6c2f15878a929c1a70e2edf69e62 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 22 May 2019 12:54:01 -0400 Subject: [PATCH 07/10] clarify wording --- proposals/1719-olm_unwedging.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 3e0ce35da..67bd6010a 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -36,8 +36,7 @@ time of the session. The spec will be changed to read: > If a client has multiple sessions established with another device, it should > use the session from which it last received and successfully decrypted a > message. For these purposes, a session that has not received any messages -> should consider its creation time to be the time that it last received a -> message. +> should use its creation time as the time that it last received a message. ## Tradeoffs From ac08c8461240e2fc9f88bc59c34263d8add4115f Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Thu, 23 May 2019 14:39:46 -0400 Subject: [PATCH 08/10] remove duplicate consideration Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/1719-olm_unwedging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 67bd6010a..c181e3f70 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -29,7 +29,7 @@ another device, it should use the session from which it last received a message." (the last paragraph of the [`m.olm.v1.curve25519-aes-sha2` section](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-olm-v1-curve25519-aes-sha2)). When comparing the time of the last received message for each session, the -client should consider only consider messages that were successfully decrypted, +client should only consider messages that were successfully decrypted, and for sessions that have never received a message, it should use the creation time of the session. The spec will be changed to read: From ffb70a2fabd46f5197cf123d6ed8bcd5d613566d Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 29 May 2019 15:01:35 -0400 Subject: [PATCH 09/10] fix typo Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/1719-olm_unwedging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index c181e3f70..5de6463f4 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -19,7 +19,7 @@ from; the client should not create a new session with another device if it has already created one for that given device in the past 1 hour. Clients may wish to ask the sender of the undecryptable messages to re-send the -message. For exampe, if the undecryptable message was a megolm session, then +message. For example, if the undecryptable message was a megolm session, then the client can send an [`m.room_key_request`](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-room-key-request) message to request that the sender re-send the key. From 6929579360113e4e653e884f7e4cb5bfa68fbbd7 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 29 May 2019 15:18:54 -0400 Subject: [PATCH 10/10] add some clarifications --- proposals/1719-olm_unwedging.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/proposals/1719-olm_unwedging.md b/proposals/1719-olm_unwedging.md index 5de6463f4..dffdc8b19 100644 --- a/proposals/1719-olm_unwedging.md +++ b/proposals/1719-olm_unwedging.md @@ -1,8 +1,13 @@ # Olm unwedging Olm sessions sometimes get out of sync, resulting in undecryptable messages. -This proposal documents a method for devices to create a new session to replace -the broken session. +This can happen for several reasons. For example, if a user restores their +client state from a backup, the client will be using an old ratchet state +([riot-web#3822](https://github.com/vector-im/riot-web/issues/3822)). Or a +client might expire a one-time key that another client is trying to use +([riot-web#3309](https://github.com/vector-im/riot-web/issues/3309)). This +proposal documents a method for devices to create a new session to replace the +broken session. ## Proposal @@ -18,11 +23,11 @@ the number of new sessions it creates per device that it receives a message from; the client should not create a new session with another device if it has already created one for that given device in the past 1 hour. -Clients may wish to ask the sender of the undecryptable messages to re-send the -message. For example, if the undecryptable message was a megolm session, then -the client can send an -[`m.room_key_request`](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-room-key-request) -message to request that the sender re-send the key. +Clients may wish to take steps to mitigate the loss of the undecryptable +messages. For example, megolm sessions that were sent using the old session +would have been lost, so the client can send +[`m.room_key_request`](https://matrix.org/docs/spec/client_server/latest.html#m-room-key-request) +messages to re-request any megolm sessions that it is unable to decrypt. The spec currently says, "If a client has multiple sessions established with another device, it should use the session from which it last received a