Re: Redirections to `Content-Encoding: encrypted` payloads

[Mike Bishop <[e-mail]>]

This is essentially the problem for which the Out-of-Band Content Encoding (https://tools.ietf.org/html/draft-reschke-http-oob-encoding) was designed. The headers (including the decryption key) are served by the origin, with the encrypted payload at a location indicated by the OOB encoding.

Sent from Nine<http://www.9folders.com/>
________________________________
From: [e-mail]
Sent: Thursday, October 1, 2020 6:01 PM
To: [e-mail]
Subject: Redirections to `Content-Encoding: encrypted` payloads

Hi, all,

I've been thinking about an extension to HTTP for a little while and am
curious whether you all think it's worth pursuing. Here's the use case:
say I have some large file, maybe a video or something. Given my server
and network resources, it's difficult for me to efficiently distribute
that file. The obvious answer to this is to use e.g. a CDN, but now I've
leaked the content of the file to the CDN. So I'd like to upload an
encrypted version of the file to the CDN, and then redirect clients to
that URL and say "by the way, here's the decryption key". I can think of
a couple ways to do this:

1. Some kind of 3xx redirect, with an additional response header to
distribute the key material. The issue with this is how the server can
tell that the client will be able to follow such a redirect.
draft-ietf-httpbis-client-hints to the rescue, maybe? (I could be wrong;
I have literally only read the introduction for that I-D.) Another issue
is what to do about headers. You don't want to leak e.g. the
Content-Type, so you can't give the headers to the CDN to serve. But,
the only other place to put them is in the original response, which is a
3xx response. So now you're sending e.g. Content-Type headers that are
basically lies, unless you encode them some other way.

2. Do option #1, but to solve the header problem define a new 3xx status
code whose semantics say that the 3xx response's headers are
authoritative, not the new location's headers. This does not seem like
an important enough use case to allocate a new status code though.

3. Do option #1, but with a header that indicates option #2's semantics.
E.g. `Redirect-Headers: use-original` or something. This also seems like
a bad idea because now the same sequence of responses can be interpreted
in completely disparate ways depending on whether the client supports
`Redirect-Headers`, which seems like a recipe for disaster (especially
because the server doesn't know in advance if the client supports
`Redirect-Headers`).

4. Something like Alt-Svc, but that worked on the resource level instead
of the origin. As a strawman let's say it's called Alt-Location. One
awkward problem with this: because the server doesn't know whether the
client will interpret the Alt-Location header, it needs to send the
response body as usual, but if the client *does* interpret the header,
it won't want the response body. Therefore the client will need to e.g.
terminate the connection. Also, if the client receives e.g. several
Alt-Svc values with different protocols, it can make an intelligent
decision about which protocol it prefers, but with Alt-Location it's not
clear how the client might pick between values.

5. Do option #4, but use Link and then add a header that explicitly
signals the client to prefer rel=alternate Links. This has the same
problem with sending the response body, though.

So, given the above, I'm wondering if the WG members have any interest
in pursuing this usecase, and if so, have any thoughts on any of the
above proposals. Is there anything I missed? Is there a decent way to do
this with the correct semantics? All of the above ideas seem wrong in
various ways.

Cheers!

-AJ