Re: Privacy difficulties in Blind Caching and OOB encoding

[Jeffrey Yasskin <[e-mail]>]

Thanks, it's good to know I didn't miss anything.

I'm thinking about this in order to re-use as much of your work as
possible in the eventual web packaging proposal. My guess for that is
that simply omitting encryption support will make it more obvious to
folks that there are lots of limitations on what secrets we can keep
from the intermediates. Does that sound plausible?

Integrity support via SRI, MICE, or a signature is still very
important, of course.

We do lose support for the case where it's fine for the intermediate
to correlate users but not ok to expose the actual bytes. Since we
keep being surprised by how much information metadata gives away, my
instinct is that this isn't a big enough space to be worth the risk;
but I'm curious if you have use cases where it is important and it's
clear that users will understand what they're exposing?

Thanks,
Jeffrey

On Thu, Aug 3, 2017 at 4:38 PM, Martin Thomson <[e-mail]> wrote:
> Hi Jeffrey,
>
> You have summarized the issues that caused us to largely abandon this
> work.  In terms of privacy, it's an increase from what traffic
> analysis would expose.  The hope was that this could be valuable in
> cases where you were prepared to expose resource identity to a cache,
> but not give it the ability to modify it, or give it control over
> meta-information.
>
> On 4 August 2017 at 04:55, Jeffrey Yasskin <[e-mail]> wrote:
>> I was reading draft-thomson-http-bc-01,
>> draft-reschke-http-oob-encoding-12, and some of their dependencies,
>> and I'm having trouble finding the plan for getting caches to actually
>> speed things up while at the same time preventing caches from learning
>> important information about the content their clients are
>> transferring.
>>
>> The core idea of the out-of-band encoding, as described in the drafts
>> and [ERICSSON], is that the origin server can delegate content
>> transmission to an edge cache to which the client has a faster
>> connection than it has to the origin.
>>
>> When we account for the origin->cache transmission, this should be
>> slower for the first client and significantly faster for all
>> subsequent clients. That is, more than one client MUST be able to use
>> the same resource bytes, which means, if they're encrypted
>> ([RFC8188]), that all clients must get the same key to decrypt them.
>> That has several implications:
>>
>> 1) For public resources, the cache can trivially figure out what
>> content clients are retrieving, by pretending to be a client itself to
>> get the decryption keys. This is an important decrease in privacy
>> compared to TLS, but I don't see it mentioned in [BC]. It seems to
>> conflict with calling the caching "blind".
>>
>> 2) For secret resources, the cache may not be able to authenticate
>> sufficiently to retrieve decryption keys, but it can still trivially
>> figure out that multiple clients are retrieving the same resource.
>> This metadata is another decrease in privacy compared to TLS.
>>
>> 3) [OOB] and [SCD] both mention a forgery risk and sketch some
>> mitigations around [SIG] and [MICE], but that's less relevant for this
>> email.
>>
>> Have I missed anything in the documents or the design that hides more
>> information from the caches?
>>
>> Thanks,
>> Jeffrey
>>
>> [BC] https://tools.ietf.org/html/draft-thomson-http-bc-01
>> [OOB] https://tools.ietf.org/html/draft-reschke-http-oob-encoding-12
>> [SCD] https://tools.ietf.org/html/draft-thomson-http-scd-02
>> [ERICSSON] https://www.ericsson.com/en/publications/ericsson-technology-review/archive/2016/blind-cache-a-solution-to-content-delivery-challenges-in-an-all-encrypted-web
>> [RFC8188] https://tools.ietf.org/html/rfc8188
>> [SIG] https://tools.ietf.org/html/draft-thomson-http-content-signature-00
>> [MICE] https://tools.ietf.org/html/draft-thomson-http-mice-02
>>