|
| 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