possible to run out of one-time-keys on rarely-used devices

[richvdh]

If you don't log into a device for ages, it is possible for the server to run out of one-time-keys, which means that new sender devices won't be able to send megolm keys to you

[richvdh]

I'm a bit short on ideas of what to do about this. I'm not super-keen on the the signal-esque fallback-to-not-using-one-time-keys, because it significantly weakens the protocol - otoh it is a relatively simple fix. Other alternatives might involve getting the sender to share the sessions later (we might even be able to keep a list of devices we wanted to share with, but couldn't? Probably related to #3019?)

#2494 might help here - we could give the sender the choice to fall back to a less secure method?

[ara4n]

I agree the Signal-style fallback is ming. Surely we can exploit megolm to help us out of this one: if we can't share megolm sessions to devices because Olm is dead, we'll need to queue the keys until that device is available again.

This could be done by OOB negotiation with a poor-man's "hit retry to try this message again" on the sender side, or we could do the whole https://github.com/vector-im/riot-web/issues/2286 thing to let the receiving device plead to receive keys from elsewhere in the room when it comes back to life.

Eitherway, it feels like we should just queue the session keys until we can send them.

[richvdh]

Interesting to note that Wire gives an explicit "You haven't used this device for a while" notice.

[richvdh]

@lampholder had this problem on a new device this evening. Hoping he and erik will share server logs to enlighten me.

[ara4n]

mastodon/mastodon#13820 (comment) has useful discussion about this.

I think we should figure out whether it's a disaster or not to have an emergency key to wriggle out of OTK exhaustion or not.

More conversation about this at https://matrix.to/#/!YRyTcRVrJzaHGZrsur:matrix.org/$zGea0UHt_Pp2DM9KsuDNl4O1bwFFsyE3OmI3zQuun08?via=matrix.org&via=ensofia.com&via=matrix.gibberfish.org

I was trying to think of an attack like:

• Alice's server admin Eve is trying to spy on her.
• Eve notices that Alice has a login somewhere on a browser she never uses (e.g. that old Chrome session she never uses since she switched to FIrefox)
• Eve snags a copy of Alice's local storage on her Chrome (e.g. via XSS), thus getting her id & OTK & backup OTK priv keys
• Eve exhausts Alice's OTK pool (e.g. by just deleting them from Alice's acct)
• Every time a new person starts an Olm session with Alice, Eve can now intercept and participate, using the backup OTK key, forever.

...but I guess the point is that by this point, Eve could also be populating up new non-backup OTKs.

[uhoreg]

This is fixed by fallback keys now