Subject: Re: [ietf-privacy] [websec] HPKP and privacy

From: SM <[email-masked]>
Date: Tue, 09 Jul 2013 17:38:34 -0700

Hi Tom,

[Cc to privacy-nuts :-)]

At 06:29 09-07-2013, Tom Ritter wrote:
>On 9 July 2013 00:23, Joseph Bonneau <[email-masked]> wrote:
> > There is no advice to implementers, however. Is there a reason not to make
> > explicit that user agents SHOULD remove pins for privacy reasons, something
> > along the lines of the text I suggested previously:
>
>It states that UAs must let people clear data:
>
> >UAs MUST have a way for users to clear current pins for Pinned Hosts.
> >UAs SHOULD have a way for users to query the current state of Pinned
> >Hosts.

I read Section 5 and missed the above (it's in Section 7).  Section 5 
basically says that HPKP can be a super-cookie.  It then explains two 
attack scenarios.  I think that the privacy considerations should be 
made explicit.

Regards,
-sm

---

From: Chris Palmer <[email-masked]>
Date: Wed, 10 Jul 2013 13:36:14 -0700

On Tue, Jul 9, 2013 at 3:54 PM, Joseph Bonneau <[email-masked]> wrote:

>> Yes. Unfortunately, I don't see a way to have both HPKP and automatic
>> defense against this kind of super-cookie. The problem exists for
>> HSTS, too.
>
> I agree, but there are two things user agents SHOULD do at a minimum: (a)
> clear pins for domains whenever other domain-specific information is cleared
> for privacy reasons (delete history since time N, or private browsing mode)

We currently have decided NOT to do this for HSTS. You can see the
somewhat tortured history of the behavior in Chrome here:

https://code.google.com/p/chromium/issues/detail?id=104935

Chrome's Incognito mode is an easy way to get Chrome to not
persistently store any local state (thus defeating a wide range of
super-cookie techniques, including but not limited to ETag, HSTS,
HPKP, cache hit/miss timing). If you are concerned about privacy
side-effects from local state, use Incognito.

(Also, it behooves me to refer to the official Incognito
documentation: https://support.google.com/chrome/answer/95464?hl=en)

> (b) not store pins in cases where cookies will not be rejected for privacy
> reasons (such as third-party cookie blocking policies). I don't think these
> are obvious to implementers so I would like to seem them in the spec.

I'm not sure what you mean here. Did you mean to write, "not store
pins in cases where cookies WILL be rejected for privacy reasons"?

Note that the HSTS and HPKP super-cookie is primarily useful for
*recovering* a previously-set but then deleted cookie — it does not by
itself allow the server to *easily* correlate requests, only to
laboriously recover a thing (like a cookie) that does. So if the UA is
blocking (say) third-party cookies anyway, the HSTS/HPKP super-cookie
technique might not work too well for the third-party adversary. Or at
least not as well as other techniques that are already available.

I believe we are in the privacy margins here. Incognito mitigates the
concern; blocking third-party cookies somewhat mitigates the concern;
N-host HSTS/HPKP super-cookies are (probably? I think?) not the most
efficient of the many available super-cookie techniques; I assume
everyone likes the report-uri feature and that we don't want to get
rid of it; et c. As far as I know, the ETag/Last-Modified super-cookie
technique is unsolved
(http://www.nikcub.com/posts/persistant-and-unblockable-cookies-using-http-headers),
and much more straightforward for implicit-tracking adversaries to
use.