[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