W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2018

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

From: Frederik Braun <fbraun@mozilla.com>
Date: Fri, 26 Oct 2018 10:39:08 +0200
To: public-webappsec@w3.org
Message-ID: <472d968a-ff06-3edf-d7e9-927d01b6c057@mozilla.com>


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

This archive was generated by hypermail 2.3.1 : Friday, 26 October 2018 08:39:34 UTC