matrix-spec-proposals/proposals/1719-olm_unwedging.md

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

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.

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`
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.
initial work on documenting olm unwedging 6 years ago			`# 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.`

we don't actually know which session got stuck, so rate-limit by device 6 years ago			`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`
1 hour seems to be fine 5 years ago			`already created one for that given device in the past 1 hour.`
initial work on documenting olm unwedging 6 years ago
add note about re-requesting megolm keys 6 years ago			`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.`

initial work on documenting olm unwedging 6 years ago			`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.`