EricssonResearch / EricssonResearch/Blind-Cache-Drafts
TLS requirements are over-broad
- Dominant language
- Makefile
- Stars
- 2
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.