Re: Privacy difficulties in Blind Caching and OOB encoding

[Martin Thomson <[e-mail]>]

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
>