Subject: Privacy difficulties in Blind Caching and OOB encoding

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 3 Aug 2017 11:55:14 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Aug 2017 09:38:20 +1000

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.

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 4 Aug 2017 10:15:50 -0700

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 5 Aug 2017 15:57:03 +1200

> from the intermediates. Does that sound plausible?

While those drafts particular approaches were problematic the encryption 
of message payloads proceeded well and became RFC 8188.

Whatever you do for the signature requirement can leverage that part to 
at last gain some protections which are expected to be interoperable 
over HTTP(S).

> clear that users will understand what they're exposing?

Have you looked at RFC 2660? while the document is woefully out of date 
in terms of crypto and quite broken in a number of other ways the idea 
of moving the identifiable non-transport headers (and maybe any 
non-standard ones from the message generator) into the encrypted portion 
can go a long way towards both security and privacy protection before it 
starts breaking HTTP.

Amos

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 24 Aug 2017 10:37:50 +0000

Hi Jeffrey,

You did a good work reading through what we¹ve published. Earlier versions
of some of the documents (never submitted to IETF and only on GitHub) had
more text about security considerations but were removed- drafts should be
brief I¹ve learnt, :-)!

I am not sure U¹ve missed it but I would like to mention that the
³toolbox² allows for different actors to run the ³blind² cache, or rather,
secondary server and in the cases where the same actor runs primary and
secondary server, a kind of ³distributed origin", some of the concerns of
what the ³blind cache¹, secondary server, sees are not applicable. This
variant is a favourite of mine, :-).

Another thing we found useful for security and privacy perspective (as
well as some others) was the control of the request routing OOB provides
meaning one can select to implement a request router (in primary server or
client (read SW in browser for instance). This was mentioned in [ERICSSON].

There is another draft FYI I just want to make sure I know about and I did
not see in your references is
https://tools.ietf.org/html/draft-eriksson-http-resource-map-00 [RMAP]. It
hints at how request routing can be done.

Best Regards
Göran

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 25 Aug 2017 20:30:17 -0700

Is there a benefit from the encryption support in the protocol, if the
major use cases don't need to worry about what the intermediates see?

Thanks,
Jeffrey

---

From: Göran Eriksson AP <[email-masked]>
Date: Sat, 26 Aug 2017 10:23:39 +0000

Is there a benefit from the encryption support in the protocol, if the major use cases don't need to worry about what the intermediates see?

You mean payload encryption? Or generally “hide” information and possibilities for secondary servers to meddle with payload?

Generally speaking, making the protocols useful for different usages is always nice- I tend to see the OOB&Co protocols as a toolbox where one pick the mechanisms that is suitable for use case at hand. So if you 100% trust that CDN, operator proxy, enterprise proxy, (someone else ) edge data centre where you deploy your secondary server, then you may decide not to encrypt (or give it the key). If you don’t, why not use payload protection (encryp/integrity protect) or even do not deliver the resource OOB.

It’s a matter of how much trust you put into the secondary server, the cloud platform (actor) you run it on and the data centre (provider’s site security) where it is  placed.

So yes, having the option is useful I would say and whether one can/should trust intermediaries in the delivery from origin to client, even if it’s the service providers “own” intermediary can be discussed.

Be well!
Göran