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. > > (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 > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
