Restart broken Olm sessions #780
Conversation
Implements matrix-org/matrix-spec-proposals#1596 For element-hq/element-web#3822 Requires matrix-org/olm-backup#77 (+release)
* Start a new Olm sessions with a device when we get an undecryptable message on it. * Send a dummy message on that sessions such that the other end knows about it. * Re-send any outstanding keyshare requests for that device. Also includes a unit test for megolm that isn't very related but came out as a result anyway. Includes #776 Fixes element-hq/element-web#3822
|
Tests failing because of https://github.com/matrix-org/olm-backup/pull/77 requirement |
| * @private | ||
| * @param {module:models/event.MatrixEvent} event undecryptable event | ||
| */ | ||
| Crypto.prototype._onToDeviceBadEncrypted = async function(event) { |
There was a problem hiding this comment.
It seems like, for example, if Alice sends Bob a message in 5 rooms, creating inbound group sessions in all 5, and then Bob comes online later on, receives all 5 messages, can't decrypt the olm session used to encrypt those group sessions, then Bob will create 5 new olm sessions, which is overkill. It would be better to remember that we already created a new session. This could be done by remembering that an olm session has already been "replaced", and if it encounters an already-replaced olm session, then it just needs to re-send the key request. It probably doesn't need to be persisted, since this situation would only happen in the short term, so it could just be stored as a member of the crypto object.
There was a problem hiding this comment.
right, so the problem with this is that only prekey messages contain information on what session ID / device key they're destined for: normal messages sent once the session has been established do not, so if we have multiple sessions, we won't know which has been replaced (when we get an incoming message, we just try decrypting it with every session we have).
There was a problem hiding this comment.
I can't think of anything better to do than a dumb heuristic like only creating one new session every hour.
There was a problem hiding this comment.
That's unfortunate. It seems like using a dumb heuristic might be the only thing to do, though every hour might be too long. Maybe something more like 10 minutes would be better, as hopefully by then, the sender would have received the m.dummy message.
|
We'll need to make an MSC to document this. So far, it looks like we'll need to document:
(I can start writing the MSC) |
| "New session already forced with device " + sender + ":" + deviceKey + | ||
| " at " + lastNewSessionForced + ": not forcing another", | ||
| ); | ||
| return; |
There was a problem hiding this comment.
I think the keyshare request should still be resent in this situation?
There was a problem hiding this comment.
I don't think so - we'll have resent all outstanding keyshare requests when the session was re-established, so any responses coming back on the old session will already have had their re-requests sent after establishment of the new session.
|
I don't think so - we'll have resent all outstanding keyshare requests
when the session was re-established, so any responses coming back on
the old session will already have had their re-requests sent after
establishment of the new session.
I'm not sure, but we can give it a go. So, lgtm.
|
As per [MSC1719](#1719) No known alterations have been made to the proposal. Implementation proof: matrix-org/matrix-js-sdk#780
message on it.
about it.
Also includes a unit test for megolm that isn't very related but came
out as a result anyway.
Includes #776
Fixes element-hq/element-web#3822