Subject: Re: [websec] HPKP and privacy

From: Joseph Bonneau <[email-masked]>
Date: Tue, 9 Jul 2013 00:23:46 -0400

There is now a section on privacy considerations in the new draft (
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-07#section-5). The
text does a nice job explaining the N-pinned-subdomains-as-supercookie
attack, and also using report-uri as a tracking mechanism.

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:

> Thinking of (a) and (b) is it worth adding a section to the spec on
> privacy considerations? The high points would be that (a) Browsers SHOULD
> remove dynamic pins for a domain whenever users request deletion of other
> browser-history state for that domain, such as a "clear history" request or
> the end of a private browsing session. (b) Browsers MAY decline to note
> pins for privacy reasons for third-party domains while browsing, similar to
> third-party cookie policies.
>
> Cheers,

Joe

---

From: Tom Ritter <[email-masked]>
Date: Tue, 9 Jul 2013 09:29:21 -0400

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.

When *should* a user agent automatically remove pins for privacy
reasons?  Any algorithm anyone comes up with will be known, and will
be bypassed with multiple domains, or whatever.

-tom

---

From: Chris Palmer <[email-masked]>
Date: Tue, 9 Jul 2013 14:43:06 -0700

> It states that UAs must let people clear data:

Yes.

> be bypassed with multiple domains, or whatever.

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.

---

From: Joseph Bonneau <[email-masked]>
Date: Tue, 9 Jul 2013 18:54:08 -0400

> > It states that UAs must let people clear data:

Ah I see this text now, I was confused since it's in a different section.

> defense against this kind of super-cookie. The problem exists for

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

Joe

---

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

Hi Tom,

[Cc to privacy-nuts :-)]

> >UAs SHOULD have a way for users to query the current state of Pinned

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:

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