[websec] HPKP and privacy
Joseph Bonneau <jbonneau@gmail.com> Sat, 22 June 2013 16:05 UTC
Return-Path: <jbonneau@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6410421F9F7D for <websec@ietfa.amsl.com>; Sat, 22 Jun 2013 09:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcrjy+l5z234 for <websec@ietfa.amsl.com>; Sat, 22 Jun 2013 09:05:17 -0700 (PDT)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20E11E80FC for <websec@ietf.org>; Sat, 22 Jun 2013 09:05:14 -0700 (PDT)
Received: by mail-ve0-f182.google.com with SMTP id ox1so7331796veb.41 for <websec@ietf.org>; Sat, 22 Jun 2013 09:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=qYWL988JuDvm3hJKVBYUEVS3adrOs+wUs9Led1c0gCA=; b=jqRFzk6gwICI8x08tQgaHgFIoorcyukzScp4rvoRQQ9gbiS8X3/YiFDYtgKTYmY8Na dCjPIifGHFSyyVos60tio1In7tnlU9QYNYyF5ZzCS/bIvSzy99kG6VWbQQpcqyUuQNj1 o6WYMl8OZP6cmR6yxTIftqP70WcgaZieHMomMJ8GGrsFcVzOUJOsgOjDRv+izDjwShA4 iN+lWCoYeBoEqzpnP8bKvsP3qvThkk503egYGsfkCJ1H0mGL89iiMiKveuo4lOHo2MFp NcBp/HWA1DQKtMZpjpnlkqpY4MjJ5CwB2bdl8fSIUCj1huIL6ZE59znNq7lzVDqAJfoI 0M1Q==
X-Received: by 10.58.219.232 with SMTP id pr8mr8240342vec.80.1371917114027; Sat, 22 Jun 2013 09:05:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.103.69 with HTTP; Sat, 22 Jun 2013 09:04:53 -0700 (PDT)
From: Joseph Bonneau <jbonneau@gmail.com>
Date: Sat, 22 Jun 2013 12:04:53 -0400
Message-ID: <CAOe4UimnDeEU3BHwy5KrCOi=4KxLPRuuKZRHQv49s1_BNg44Ww@mail.gmail.com>
To: "<websec@ietf.org>" <websec@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bd6b88c3e373904dfc058b8"
Subject: [websec] HPKP and privacy
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jun 2013 16:05:18 -0000
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] HPKP and privacy Joseph Bonneau
- Re: [websec] HPKP and privacy Tobias Gondrom
- Re: [websec] HPKP and privacy Joseph Bonneau
- Re: [websec] HPKP and privacy Tom Ritter
- Re: [websec] HPKP and privacy Chris Palmer
- Re: [websec] HPKP and privacy Joseph Bonneau
- Re: [websec] HPKP and privacy SM
- Re: [websec] HPKP and privacy Chris Palmer