TLS requirements are over-broad

[MikeBishop]

SCD says (section 7):

This design relies on integrity and confidentiality for the request
and response made to the origin server. These requests MUST be made
using HTTP over TLS (HTTPS) [RFC2818] only. Though there is a lesser
requirement for confidentiality, requests made to the CDN cache MUST
also be secured using HTTPS.

This feels like TLS because TLS, not an actual threat model output. It seems like the actual threats we need to consider and discuss in the draft are:

1. Intermediary can observe what requests are being made (tracking by third party)
2. Intermediary can read content (confidentiality from third party)
3. Intermediary can modify content (integrity from third party)
4. Cache can observe what requests are being made (tracking by cache)
5. Cache can read content (confidentiality from cache)
6. Cache can modify content (integrity from cache)

4 and 5 are already covered in sections 4 and 7.1, and are admitted as being intractable for public content. But that's fine, since if the content is public the origin obviously doesn't care about the confidentiality of it. Even for non-public content, 4 is partially intractable, since the cache can still correlate which clients are requesting the content, even if it can't (immediately) identify it. You already cover this in 7.3.

TLS is a defense against attacks 1-3. But the key point is in the previous paragraph: "without losing integrity with respect to the content that is distributed." This method is perfectly functional when used with http:// origins -- it's simply as vulnerable to attackers as any other http:// content. If the content being served is unencrypted, there's no reason this method couldn't still be used -- but the origin server obviously isn't concerned about attacks 1-3, just as we've already conceded it's not concerned about 4-5 in all cases.

Failure to use TLS when connecting to the cache exposes you to some correlation by observers, so I can see why you'd want to use TLS to the cache for https:// resources even when the content being transferred is already encrypted.

A more reasonable requirement would be that the connection to the cache MUST use TLS if the connection to the origin server did. This maintains the stated goal, that security has not been degraded with respect to the content being distributed.

[gaperik]

Just to confirm my understanding; You say in case http://example.com, TLS not a required to the CDN/cache? What if secure origin (https://github.com) with mixed content meaning some http:// sub-resources? You would propose to have TLS not required either there as well?

Regards
GE

[MikeBishop]

There are two pivots for TLS – can a CDN be used for an http:// resource, or is it constrained to https:// resources only? The spec currently seems to suggest that it’s constrained, and I don’t agree that this is necessary. If I’m misreading the spec, you can repurpose this issue to clarify my misunderstanding, of course. ☺
The second pivot is whether TLS is required on the second leg, talking to the CDN. For an https:// resource, it probably is – it prevents third-party tracking of the resources you’re accessing from the cache, which may be well-known or at least correlatable. For an http:// resource, I’m still of mixed opinion and haven’t taken a position on that yet.

I don’t think mixed resources come into play at the HTTP layer – there’s a resource identified by a URL, and we’re retrieving it. How we acquired that URL is irrelevant – the URL itself contains the desired scheme, and if that scheme differs from the scheme of the resource where we found the URL, that’s above our layer. If the browser wants to upgrade scheme in that case, it should be doing so before it reaches the HTTP implementation.

From: Göran AP [mailto:[email protected]]
Sent: Thursday, March 31, 2016 7:01 AM
To: EricssonResearch/Blind-Cache-Drafts [email protected]
Cc: Mike Bishop [email protected]
Subject: Re: [EricssonResearch/Blind-Cache-Drafts] TLS requirements are over-broad (#2)

Just to confirm my understanding; You say in case http://example.com, TLS not a required to the CDN/cache? What if secure origin (https://github.com) with mixed content meaning some http:// sub-resources? You would propose to have TLS not required either there as well?

Regards
GE

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-203953468

[gaperik]

Leaving it to @martinthomson, @reschke et. al to give their view, I must admit I have been focusing on the case of delegating delivery of https:// resource in a secure origin context but I do recognize the relevance of your question concerning the other use case, i.e. delegating delivery of http payload via a 3rd party.
That is possible today with existing mechanisms, is it not or are You after also making that a bit more 'secure', reusing some of the SCD mechanisms, such as payload encryption, MICE and the way oob-encoding send the mapping info over a TLS between the client and the origin?

The use case is relevant indeed.

And I can see several interesting discussions around the corner here, :-).

[martinthomson]

I guess that it wasn't clear here what the goals were, but I'm not at all interested in developing new features without security. So much so that I didn't even consider the possibility that someone might ask what is - in retrospect - a pretty obvious question.

[gaperik]

Is this still relevant?

[gaperik]

The question is whether we want to forbid use of HTTP and allow only HTTPS? There is for example the deployment with the secondary server behind an Enterprise FW/NAT in which case TLS may be omitted...

[martinthomson]

I don't see any value in creating carve-outs for special cases. Clients aren't able to tell that the network is "secure enough" so that they can decide that HTTP is OK. The secondary server can deploy HTTPS.

[gaperik]

(Warning- exploratory question to review current proposal and not an final opinion of this author) Of course, clients do not decide on to TLS or not TLS- origins do. What you're saying more or less is that all resources should be https://, even google-analytics.js...

I guess the value would be to give the content provider the possibility to choose by not MUST'ing.

The added cost of using SCD/BC-Proxy are TLS, payload encryption and integrity protection. If the content provider/CDN is not so keen on doing this two options remains; putting "non-sensitive" resources on a separate http domain or deploy their own https origin server deep in the network and use various ideas to get cert/key to that really deep, remote (from content provider own data centre perspective) edge origin. Not so nice- neither this particular edge origin solution nor having to use different ways to treat sensitive and "non-sensitive" resources.

I do not think this is about special case- it can also be about lowering the barrier for deploying something SCD/BC-Proxy. Also, enterprise proxies are not special cases are they- after all we did change the interface between the secondary and the origin(primary) to handle the case that it can be behind a NAT/FW using a fetch.

In any case, making the SCD as "light-weight" as possible for non-sensitive resources is something we should discuss. Is payload encryption always necessary for google-analytics.js?