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

@Mike West <mike@mikewest.org> any thoughts on Frederik's question?

On Fri, Oct 26, 2018 at 3:41 AM Frederik Braun <fbraun@mozilla.com> wrote:

>
>
> 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
>
>

-- 
Caleb
571-228-8011