Subject: [websec] HPKP and privacy

From: Joseph Bonneau <[email-masked]>
Date: Sat, 22 Jun 2013 12:04:53 -0400

Reading over the new draft I was thinking of the privacy considerations of
HPKP. A few thoughts:

(a) Obviously the state of a user's pin store contains a lot of information
about their browsing history. This is a primary concern.

(b) A clever site could use this as a tracking mechanism to evade
third-party cookie limits or other restrictions. For example, a tracking
domain could have a set of N public keys available for use, pin different
users to a unique sets of them, and then be included as N resources on a
third-party page. By noting which TLS connections lead to actual data
transfers, they can identify the user uniquely. This is an exotic threat
model, perhaps, but it might become interesting if protection against other
forms of third-party tracking improves.

(c) Potentially HPKP could be used for history sniffing, though I can't
think of a way to do this without the adversary having network-level access
and malicious certificats for the target domain.

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.

Joe

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 24 Jun 2013 15:09:03 +0800

Hi,

<no hats>
I agree with the overall point of adding information on privacy concerns
in the draft.

I would agree with (a) and rather unlikely (c).
Regarding (b): Actually maybe I misunderstand something, but I think it
would be rather suicidal of a web page to try (b) because the pin acts
before or at the establishment of the TLS connection. So you have no
idea who the other party is yet and will most likely brick a lot of your
users if you try to give them different pins that then don't work. But
maybe I missed something?

Best regards, Tobias

On 23/06/13 00:04, Joseph Bonneau wrote:
> Reading over the new draft I was thinking of the privacy
> considerations of HPKP. A few thoughts:
>
> (a) Obviously the state of a user's pin store contains a lot of
> information about their browsing history. This is a primary concern.
>
> third-party cookie limits or other restrictions. For example, a
> tracking domain could have a set of N public keys available for use,
> pin different users to a unique sets of them, and then be included as
> N resources on a third-party page. By noting which TLS connections
> lead to actual data transfers, they can identify the user uniquely.
> This is an exotic threat model, perhaps, but it might become
> interesting if protection against other forms of third-party tracking
> improves.
>
> (c) Potentially HPKP could be used for history sniffing, though I
> can't think of a way to do this without the adversary having
> network-level access and malicious certificats for the target domain.
>
> 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. 
>
> Joe
>
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec