From 21c7591f34c3fc40ae48a53e968b611f0eeb50f3 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 6 Feb 2024 16:39:39 -0700 Subject: [PATCH] Interactions between media redirection and authentication --- proposals/4097-media-redirect-with-auth.md | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 proposals/4097-media-redirect-with-auth.md diff --git a/proposals/4097-media-redirect-with-auth.md b/proposals/4097-media-redirect-with-auth.md new file mode 100644 index 00000000..78c12d4b --- /dev/null +++ b/proposals/4097-media-redirect-with-auth.md @@ -0,0 +1,60 @@ +# MSC4097: Interactions between media redirection and authentication + +With the introduction of [MSC3860 (merged)](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/3860-media-download-redirect.md), +media download requests can be redirected to a CDN or other resource, allowing server owners to reduce +costs of hosting a Matrix homeserver. [MSC3916 (proposed)](https://github.com/matrix-org/matrix-spec-proposals/pull/3916) +introduces a concept of authenticating those download requests. Authentication alone doesn't prevent +the ability to use a CDN (the client simply authenticates its request, then gets redirected), however +with follow-up MSCs like [MSC3911 (proposed)](https://github.com/matrix-org/matrix-spec-proposals/pull/3911), +the media the client is trying to download may be linked to an event and thus should not be viewable +by sharing the link to third parties. + +The abstract concept of preventing users from sharing download links with users/clients not in the room +is tricky to resolve in a way where a CDN can still operate. CDNs are not typically capable of doing +the authentication check themselves during the download request, necessitating a Matrix-aware application +layer to perform that authentication. The layer can still redirect to the CDN, but that then opens up +an opportunity for the user to copy/paste the link again. + +Some server operators may be tolerable to this risk or decide that a time-limited URL with the CDN is +suitable for their use case. Others, however, may still wish to use a CDN *and* prevent most cases of +copy/paste from working. + +This proposal covers that use case. A symmetric encryption key is generated by the server after the +request is authenticated, injected into the CDN, and then returned to the client alongside the +redirect. The client then follows the redirect and requests the media from the CDN. The CDN encrypts +the media download on the fly using the symmetric key, and the client decrypts it before serving it +to the user (or before further decrypting it, if the media is in an encrypted room). If the user were +to share the redirected URL, the requester would get encrypted content back unless the user also extracted +the key from their client. + +Most notably, this behaviour is *opt-in*. Both the client and server can decide to use a different +approach for serving media, though that approach may have lesser security/privacy. + +**TODO**: Consider not re-encrypting media that's in an encrypted room already. It's simpler to encrypt +everything, but if we already know the event ID contains encrypted content because we've linked it to +the media ID, we can probably assume it'll be fine enough to serve verbatim. + +## Proposal + +**TODO**: The words! Somehow the client needs to get the key (`/config`?), and needs to know how to use +it. Also, pick an encryption algorithm. + +## Potential issues + +**TODO**: This section. + +## Alternatives + +**TODO**: This section. + +## Security considerations + +**TODO**: This section. + +## Unstable prefix + +**TODO**: This section. + +## Dependencies + +**TODO**: This section.