MSC3673: Encrypted ephemeral data units

[stefanceriu]

In which we build on top of MSC2476: User-defined ephemeral events and define a way to encrypt custom EDUs.

Rendered

Shepherd: @anoadragon453

[uhoreg]

I think it would be worth clarifying whether you can use the same megolm session for normal room events and for ephemeral events. (FWIW, I think you should use a separate megolm session, and that it should have the shared_history property (MSC3061) flag unset)

[stefanceriu]

Unfortunately I don't know much about how that works. Would adding a new session significantly complicate things client side? Also, what are the advantages/disadvantages?

[dkasak]

The advantage of using separate keys is increased confidentiality protection against malicious homeserver attacks.

The HS could store encrypted EDUs indefinitely since all EDUs have to pass through it. If we used regular Megolm sessions ("room keys") for encrypting EDUs, then in the event that the server somehow managed to get a hold of the regular session, it would also have complete historical visibility of the EDUs sent during the time that this session was active. Using an unshareable separate Megolm session for this purpose alleviates this risk.

The disadvantage is that it increases to-device traffic and the number of Megolm sessions and session operations, which can be slow. If it turns out to be a problem, we could allow EDU Megolm sessions to be rotated slower than normal sessions.

[robryk]

In what scenarios would you expect the homeserver to be able to get ahold of a regular session, but not of the separate session for EDUs? I would naively expect the same set of entities to have keys for both, so also any compromise to affect both or neither.

[dkasak]

Not any legitimate scenarios, but there can always be implementation bugs. From my POV, this is just an extra degree of separation for some extra hardening, so that stealing one does not compromise the other.

I would naively expect the same set of entities to have keys for both, so also any compromise to affect both or neither.

Room keys are probably in a bit of a worse position since they get forwarded/re-shared to other devices in several situations (for instance, upon m.room_key_request), whereas EDU keys don't need to support forwarding since the EDUs themselves are ephemeral. So in the event of an undecryptable EDU, we can just drop it and rotate the key.

[ananace]

I feel like there should be some mention of how this will interact with power levels.
Server should probably allow clients to send the suggested m.room.encrypted ephemeral type after all, and the clients might maybe want to reference the power levels as well - in regards to what EDUs they should actually handle.

[anoadragon453]

Heads up that @stefanceriu has moved on to other work. In their place I'll be acting as a shepherd and will be updating this MSC as new feedback comes in.