Re: [clear-site-data] User Tracking via TLS Session Resumption

Am 25.10.18 um 16:57 schrieb Caleb Queern:
> Just want to confirm my understanding... if one were worried about
> the risk of user tracking via TLS session resumption as described in
> the Hamburg paper, that risk would be mitigated in browsers that
> support the Clear-Site-Data header by sending the header:
> 
> Clear-Site-Data: "cache"
> 
> ...correct?
> 

Looking at
<https://mikewest.github.io/webappsec/specs/clear-site-data/#cache-parameter>,
it says

> The cache parameter indicates that the server wishes to remove
> locally cached data associated with the origin of a particular
> response’s url. This includes the network cache, of course, but will
> also remove data from various other caches which a user agent
> implements (prerendered pages, script caches, shader caches, etc.).
This reads to me as a "probably not".
I would have assumed that this is purely about cached *content*.
So should it include all kinds of things a browser could have cached for
this origin? Issue 5 in the spec[1] agrees that this is a bit nebulous
and Chrome appears to remove some of those things

What are other people reading into this?
Should "cache" include TLS session information?
If not, should there be some sort of security-state flag for the
Clear-Site-Data header which removes existing security state (e.g.,TLS
session tickets, HPKP/HSTS values set through headers (assuming browser
support)?





[1]
https://mikewest.github.io/webappsec/specs/clear-site-data/#issue-d40aa458

Received on Friday, 26 October 2018 08:39:33 UTC