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

Hi Scott, good to hear from you. You're right - the scenario I described is
unlikely.

I'm not so much hoping to learn if the scenario makes sense but rather to
clarify - as Frederik put it - whether Clear-Site-Data header removes
existing security state (e.g.,TLS session tickets, HPKP/HSTS values set
through headers, etc).

Like Frederik, my interpretation of the spec is that CSD applies only to
cached *content* and does not remove existing security state but I just
wanted to confirm for the record. If that is the case perhaps that
clarification would make a good enhancement to the spec.


On Thu, Nov 1, 2018 at 3:04 AM Scott Helme <scotthelme@hotmail.com> wrote:

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


-- 
Caleb
571-228-8011