Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC1719: olm session unwedging #1719

Merged
merged 10 commits into from
Jun 4, 2019
Merged

MSC1719: olm session unwedging #1719

Changes from 4 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
b535226
initial work on documenting olm unwedging
uhoreg Nov 14, 2018
d0bfdc1
rename to match MSC number
uhoreg Nov 14, 2018
495df02
we don't actually know which session got stuck, so rate-limit by device
uhoreg Nov 14, 2018
2b58052
add note about re-requesting megolm keys
uhoreg Nov 14, 2018
7705006
1 hour seems to be fine
uhoreg May 22, 2019
d39baba
add a security note
uhoreg May 22, 2019
dd74baa
clarify wording
uhoreg May 22, 2019
ac08c84
remove duplicate consideration
uhoreg May 23, 2019
ffb70a2
fix typo
uhoreg May 29, 2019
6929579
add some clarifications
uhoreg May 29, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions proposals/1719-olm_unwedging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Olm unwedging

Olm sessions sometimes get out of sync, resulting in undecryptable messages.
richvdh marked this conversation as resolved.
Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this is already working in practice - but sometimes I receive undecryptable messages that I can decrypt after a little why. Possibly this MSC is the reason it does eventually become decrypted? But I was always chalking it up to server lag. If the latter is the case, shouldn't we wait a little bit before attempting to start another session? Or does rate limiting make this all ok anyways?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With megolm, if you receive a message that you can't decrypt, then it could be that the key will come in later, and then you'll be able to decrypt it. With olm, if you receive a message that you can't decrypt, then there's no way to recover, and waiting for a while won't help.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can m.dummy only be sent in the context of unwedging? If not, how should the client handle it? By ignoring the event the client opens itself up to problems similar to https://github.com/vector-im/riot-web/issues/3261

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably doesn't necessarily need to be in the context of unwedging, but I can't really think of any other reason a client would send a dummy message, and I think we could just define m.dummy as "Ignore this message". This is a to_device message, and won't be displayed in any way to the user, so I don't think it will introduce any problems in the timeline.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I thought this was a timeline event. Would be good to clarify that it is a to_device event (if it isn't already - I'm willing to believe I just missed that).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's kind of hidden in the fact that the message is olm-encrypted. I guess that technically, it could be a timeline event, if you used olm for your room encryption rather than megolm, but ... let's just say that people won't do that. ;)

empty contents.

In order to avoid creating too many extra sessions, a client should rate-limit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can a client DoS another client by ignoring this rate limit? Does the server protect against this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A client could drain another client's one-time keys, preventing others from starting sessions. There isn't really a good way of fixing that. Note that this MSC doesn't change what a client is able to do, so any DoS that one client can perform with this MSC could also be done without the MSC.

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?)
uhoreg marked this conversation as resolved.
Show resolved Hide resolved

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
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
richvdh marked this conversation as resolved.
Show resolved Hide resolved
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,
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sounds like it fixes element-hq/element-web#2330, and maybe element-hq/element-web#4011 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think 4011 was an implementation issue that was fixed by matrix-org/matrix-js-sdk#857. But this does fix 2330 -- I had been waiting for more testing before closing it.

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