IETF Logo Mail Archive

Re: [websec] New draft of HTTP header-based public key pinning

Adam Barth <ietf@adambarth.com> Wed, 09 November 2011 09:21 UTC

Return-Path: <ietf@adambarth.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 806B721F8B5B for <websec@ietfa.amsl.com>; Wed, 9 Nov 2011 01:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 MJCOI2GyHGl9 for <websec@ietfa.amsl.com>; Wed, 9 Nov 2011 01:21:01 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8151221F8B59 for <websec@ietf.org>; Wed, 9 Nov 2011 01:21:01 -0800 (PST)
Received: by iaeo4 with SMTP id o4so1981027iae.31 for <websec@ietf.org>; Wed, 09 Nov 2011 01:21:00 -0800 (PST)
Received: by 10.42.197.195 with SMTP id el3mr1434743icb.54.1320830460120; Wed, 09 Nov 2011 01:21:00 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p16sm6082240ibk.6.2011.11.09.01.20.58 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 01:20:58 -0800 (PST)
Received: by iaeo4 with SMTP id o4so1980995iae.31 for <websec@ietf.org>; Wed, 09 Nov 2011 01:20:58 -0800 (PST)
Received: by 10.231.73.196 with SMTP id r4mr360822ibj.19.1320830458131; Wed, 09 Nov 2011 01:20:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 01:20:27 -0800 (PST)
In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com>
References: <CAOuvq21Ne0CWT3Dzn0sutGDBg0K+efZhxmqBZiLuxbO2OwxnFg@mail.gmail.com> <CA+cU71kFFpuooyiBTarvLT3VJigZhW0BgpQi1gMTn7zB=sFh+w@mail.gmail.com> <CAOuvq20uCZsp80yJ6gjeh-AGVswu3GTPuSYYCGyXPWpO-RJpsA@mail.gmail.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 09 Nov 2011 01:20:27 -0800
Message-ID: <CAJE5ia9Ryjus6Zy38PFffCnGsZHw+byvdTVCi7XmYWUd8rVdTQ@mail.gmail.com>
To: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Chris Evans <cevans@google.com>, IETF WebSec WG <websec@ietf.org>, Ian Fette <ifette@google.com>, Wan-Teh Chang <wtc@google.com>
Subject: Re: [websec] New draft of HTTP header-based public key pinning
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: Wed, 09 Nov 2011 09:21:02 -0000

On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> wrote:
>> -----Original Message-----
>> From:  Chris Palmer
>> >  - There is no directive or suggestion to User Agents about saving or
>> > not saving pins received in a private browsing mode.  Maybe there
>> > shouldn't be, but if a User-Agent does save them, the same 304/ETag
>> > trick malicious sites use to track users can be created using certs
>> > and subdomains.
>>
>> Yes, another person raised this concern, and it is real. I don't see a way to
>> resolve this problem; perhaps I am not smart enough, but I can't see a way to
>> have both dynamic pinning AND avoid this tracking attack.
>>
>> I am willing to add a paragraph about what browsers should do in private
>> browsing mode, and I am willing to go either way on what the requirement
>> should be. I don't know what is best.
>
> We battled this problem with HSTS as well.  I think what Mozilla settled on (and I don't remember the Chrome solution) is to use a different storage mechanism when HSTS is *set* during private browsing mode, and clear on exit from private browsing.

It's been a while since I wrote that code, but I'm pretty sure that's
how it works in Chrome too.  There's a separate memory-only HSTS store
that's used for incognito.  That's consistent with how we handle other
host-specific data stored by the network layer, such as cookies.

Adam


> Clearing history/cookies on the browser is similarly problematic for HSTS and pinning.  This is unfortunate in that we'd really like it to be hard for users to clear HSTS state because it is "good for them".  Not clear whether this belongs in the spec, or a set of implementation guidelines.  Folks got squeamish here about talking about exact UA behavior, etc.
>
> There is a Firefox bugzilla bug about this issue, I'll try to go find it and post back here unless someone beats me to it.
>
> - Andy
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>

v2.23.0 | Report a Bug | By Email