Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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
MSC3673: Encrypted ephemeral data units #3673
base: main
Are you sure you want to change the base?
MSC3673: Encrypted ephemeral data units #3673
Changes from 2 commits
066acda
7ba8e27
7fdf81a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.