Skip to content

Commit b92b147

Browse files
authored
Merge pull request #1719 from uhoreg/olm_unwedging
MSC1719: olm session unwedging
2 parents 9dd171a + 6929579 commit b92b147

File tree

1 file changed

+59
-0
lines changed

1 file changed

+59
-0
lines changed

proposals/1719-olm_unwedging.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# Olm unwedging
2+
3+
Olm sessions sometimes get out of sync, resulting in undecryptable messages.
4+
This can happen for several reasons. For example, if a user restores their
5+
client state from a backup, the client will be using an old ratchet state
6+
([riot-web#3822](https://github.com/vector-im/riot-web/issues/3822)). Or a
7+
client might expire a one-time key that another client is trying to use
8+
([riot-web#3309](https://github.com/vector-im/riot-web/issues/3309)). This
9+
proposal documents a method for devices to create a new session to replace the
10+
broken session.
11+
12+
## Proposal
13+
14+
When a device receives an olm-encrypted message that it cannot decrypt, it
15+
should assume that the olm session has become corrupted and create a new olm
16+
session to replace it. It should then send a dummy message, using that
17+
session, to the other party in order to inform them of the new session. To
18+
send a dummy message, clients may send an event with type `m.dummy`, and with
19+
empty contents.
20+
21+
In order to avoid creating too many extra sessions, a client should rate-limit
22+
the number of new sessions it creates per device that it receives a message
23+
from; the client should not create a new session with another device if it has
24+
already created one for that given device in the past 1 hour.
25+
26+
Clients may wish to take steps to mitigate the loss of the undecryptable
27+
messages. For example, megolm sessions that were sent using the old session
28+
would have been lost, so the client can send
29+
[`m.room_key_request`](https://matrix.org/docs/spec/client_server/latest.html#m-room-key-request)
30+
messages to re-request any megolm sessions that it is unable to decrypt.
31+
32+
The spec currently says, "If a client has multiple sessions established with
33+
another device, it should use the session from which it last received a
34+
message." (the last paragraph of the [`m.olm.v1.curve25519-aes-sha2`
35+
section](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-olm-v1-curve25519-aes-sha2)).
36+
When comparing the time of the last received message for each session, the
37+
client should only consider messages that were successfully decrypted,
38+
and for sessions that have never received a message, it should use the creation
39+
time of the session. The spec will be changed to read:
40+
41+
> If a client has multiple sessions established with another device, it should
42+
> use the session from which it last received and successfully decrypted a
43+
> message. For these purposes, a session that has not received any messages
44+
> should use its creation time as the time that it last received a message.
45+
46+
## Tradeoffs
47+
48+
## Potential issues
49+
50+
## Security considerations
51+
52+
An attacker could use this to create a new session on a device that they are
53+
able to read. However, this would require the attacker to have compromised the
54+
device's keys.
55+
56+
## Conclusion
57+
58+
This proposal outlines how wedged olm sessions can be replaced by a new
59+
session.

0 commit comments

Comments
 (0)