You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec/proposals/1719-olm_unwedging.md

2.3 KiB

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. (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 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). 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.