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

If a site was tracking users with a TLS session ticket/id then wouldn’t they have zero motive to issue the Clear-Site-Data header in HTTP responses? (assuming it did clear the ticket/id)

Perhaps I missed something, and please point out if I have, but it doesn’t seem that CSD could/would work as mitigation for this. It depends on the host doing the tracking to issue the header to stop tracking and they seem to be conflicting interests.


From: Caleb Queern <cqueern@gmail.com>
Sent: 01 November 2018 07:22
To: fbraun@mozilla.com; Mike West <mike@mikewest.org>
Cc: public-webappsec@w3.org
Subject: Re: [clear-site-data] User Tracking via TLS Session Resumption

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

On Fri, Oct 26, 2018 at 3:41 AM Frederik Braun <fbraun@mozilla.com<mailto: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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikewest.github.io%2Fwebappsec%2Fspecs%2Fclear-site-data%2F%23cache-parameter&data=02%7C01%7C%7C153ed27b373443d50fe708d63fcb0644%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766538540807826&sdata=B4MjTT36i%2FzVAGN0Tl3HqZk%2Fsu%2FSNXpMPzdyfVm1p1o%3D&reserved=0>>,
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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikewest.github.io%2Fwebappsec%2Fspecs%2Fclear-site-data%2F%23issue-d40aa458&data=02%7C01%7C%7C153ed27b373443d50fe708d63fcb0644%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766538540807826&sdata=ab1wx5TSKhpX4Mw5nLc4JBCoQm5jgT7xAzyZ6cy2y8M%3D&reserved=0>


--
Caleb
571-228-8011