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

Hello Team.

This thread has aged a bit but it feels like some unanswered questions
remain about exactly what CSD can affect.

Frederik asked:

...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)?


Dan asked:

Are TLS session tickets more like that or more like cache? Even if they
> aren't really auth-like things would it be less confusing to lump all the
> TLS-tracking things together?

...Do we expect users of Clear-site-data to pick and choose types, or are
> they just going to use "*" in practice?
>

 Just wanted to revive the thread in case things have become clearer or
opinions have evolved since we discussed in November.


On Thu, Nov 1, 2018 at 6:11 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Fri, Oct 26, 2018 at 1:41 AM Frederik Braun <fbraun@mozilla.com> wrote:
>
>> 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)?
>>
>
> The spec already has the "cookies" parameter clear TLS Channel ID and
> bound tokens.
> https://w3c.github.io/webappsec-clear-site-data/#clear-cookies
>
> Are TLS session tickets more like that or more like cache? Even if they
> aren't really auth-like things would it be less confusing to lump all the
> TLS-tracking things together?
>
> Do we expect users of Clear-site-data to pick and choose types, or are
> they just going to use "*" in practice?
>
> -Dan Veditz
>