MSC4268: Sharing room keys for past messages#4268
Conversation
turt2live
added
A-Encryption
This comment was marked as resolved.
This comment was marked as resolved.
This event is defined in MSC4268. MSC4268: matrix-org/matrix-spec-proposals#4268
This event is defined in MSC4268. MSC4268: matrix-org/matrix-spec-proposals#4268
This event is defined in MSC4268. MSC4268: matrix-org/matrix-spec-proposals#4268
This event is defined in MSC4268. MSC4268: matrix-org/matrix-spec-proposals#4268
…cryption-info feat: Add `forwarder: ForwarderInfo` to `EncryptionInfo`. Introduces `ForwarderInfo` which which exposes information about the forwarder of the keys with which an event was encrypted if they were shared as part of an [MSC4268](matrix-org/matrix-spec-proposals#4268) room key bundle.
Expose information about the forwarder for events that were decrypted using a key from an [MSC4268](matrix-org/matrix-spec-proposals#4268) key bundle. Signed-off-by: Skye Elliot <actuallyori@gmail.com>
richvdh
changed the title
github-project-automation
Bot
moved this to Tracking for review
in Spec Core Team Workflow
richvdh
moved this from Tracking for review
to Ready for FCP ticks
in Spec Core Team Workflow
turt2live
added
the
00-weekly-pings
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
no blocking concerns - thank you!
| however, that this process must be resilient to Bob's client being restarted | ||
| before the download/import completes. | ||
|
|
||
| The definition of "recently" is left up to clients. (They should consider |
There was a problem hiding this comment.
Imposing a limit in the spec feels like we'd also be limiting use cases. Instead, because clients with slightly obscure requirements (such as availability) are typically attached to servers which are aware of those requirements, we can likely move this timeout in part to the server.
The client should still make its own decisions about what to request, but the server should also decide how long it keeps bundles around for. These two values may not be the same, and can lead to download failures: this is acceptable, in my opinion. A future MSC can introduce a re-request mechanism if it becomes a high enough priority issue.
(this is non-blocking for FCP in my opinion: I'm fine with the text as-written, but would appreciate a note that the server might delete things before the client can request it)
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
| until we have authenticated backups (MSC4048). This is tracked at | ||
| https://github.com/matrix-org/matrix-rust-sdk/issues/5110. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
How big can this bundle get? Will (de)serializing it cause potential memory issues with clients? Do we need to allow for multiple?
There was a problem hiding this comment.
It's limited only by the size limits on the media store (e.g. 50MB by default for Synapse, 10MB for matrix.org's free tier). Some discussion about this here.
We're basically assuming that clients can safely decrypt and hold in memory anything that the media store can send them, so I'm not too worried about us blowing out memory limits.
At the other end, it has to be said that matrix.org's paid tiers have been introduced since we started this project, and it's not inconceivable that people will hit the 10MB limit if they invite someone to a massive encrypted room. That said (a) that sounds like the level of usage where they should be either paying or going elsewhere, and (b) even if we want to support multiple bundles in future, I'd much rather leave that until we're sure we need it.
There was a problem hiding this comment.
Thanks, I'm not sure if any of this is worth adding to the MSC? Maybe just a "clients may generate a file too large to upload, in which case they should do X"? Not sure it is worth it as a callout.
There was a problem hiding this comment.
I've added a more explicit note in the "Potential Issues" section in 31fa0dd. I don't have any great suggestions for what clients should do about it right now, so I'm glossing over that bit.
| * Ideally, the bundle would be deleted once the recipient has successfully | ||
| downloaded it. An implementation is left for a future MSC, such as | ||
| [MSC4425](https://github.com/matrix-org/matrix-spec-proposals/pull/4425). This | ||
| is tracked at https://github.com/matrix-org/matrix-rust-sdk/issues/5113. |
There was a problem hiding this comment.
Deleting the bundles being out of scope feels very not nice, but I guess it's not the end of the world since it's encrypted with AES-256 which isn't expected to be cracked by quantum computers
| @@ -0,0 +1,468 @@ | |||
| # MSC4268: Sharing room keys for past messages | |||
There was a problem hiding this comment.
My two main concerns on this MSC are:
-
Without the ability to delete key bundles once they've been consumed by the invited user, we accumulate encrypted key material in a way which is tantamount to harvest-now-decrypt-later attacks. However, given MSC4425 (or other ephemeral MSCs) are on the radar, I'm (just about) happy to for this to progress on the understanding that we follow up afterwards rapidly with MSC4425 or similar.
-
In terms of use experience, it's really not obvious to me that the common case should be to share all possible keys with an invited user. Sometimes this will be important (e.g. knowledge transfer to a new user joining a team/org) - but sometimes it will be very undesirable even if the room has shared history viz, particularly if the history viz been changed back and forth over time. I suspect that an approach similar to the WhatsApp idiom of "how much history do you want to share with the new user? nothing? 1 msg? 100 msgs? everything?" might help with this. However: this is a client UX question and is already supported by the MSC.
So, neither of these points end up being blocking, although both make me quite uncomfortable with the proposal. I'll checkbox it to proceed, but please can we track these concerns on the Element crypto-team agenda so they're not lost.
There was a problem hiding this comment.
- Without the ability to delete key bundles once they've been consumed by the invited user, we accumulate encrypted key material in a way which is tantamount to harvest-now-decrypt-later attacks. However, given MSC4425 (or other ephemeral MSCs) are on the radar, I'm (just about) happy to for this to progress on the understanding that we follow up afterwards rapidly with MSC4425 or similar.
This is already tracked at matrix-org/matrix-rust-sdk#5113, though I would say that we'd need to deprioritise some other scheduled work for any followup to be rapid.
In terms of use experience, it's really not obvious to me that the common case should be to share all possible keys with an invited user.
My inclination on this is to deliver the implementation we have and see what feedback we get.
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
turt2live
removed
the
00-weekly-pings
mscbot
added
the
unresolved-concerns
mscbot
removed
the
unresolved-concerns
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
turt2live
added
spec-pr-missing
13 participants
A proposal for sharing the keys to existing room messages when inviting someone to a room.
This reintroduces the functionality previously proposed in MSC3061.
Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Cryptography team.
The functionality discussed here is implemented in current versions of Element Web and Element X.
Rendered
MSC checklist
FCP tickyboxes