Re: [websec] #57: Re-add an upper limit to max-age

Ryan Sleevi <sleevi@google.com> Fri, 29 March 2013 21:15 UTC

Return-Path: <sleevi@google.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 4805A21E804D for <websec@ietfa.amsl.com>; Fri, 29 Mar 2013 14:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level:
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 ZUgNaHn9in6x for <websec@ietfa.amsl.com>; Fri, 29 Mar 2013 14:15:31 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2B55821E804E for <websec@ietf.org>; Fri, 29 Mar 2013 14:15:24 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id x14so931007ief.21 for <websec@ietf.org>; Fri, 29 Mar 2013 14:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=d1PBt4TCgMUHpGPAgVF3qhNY5OmS1uD9n2jgD+w8Zg0=; b=I/CWcNNqTkoA/57NvWZZCipdgkjUkHbW3oXMr9WMcGpUh4XKs0BwFdG849e/qha7JY tIBrlNSLb+G4xFTQ1H95IHbdDS8mu7RtygABqzGumMMU7dtBAUGzJ/80NPRr4zqEX3SB 5aSQjisQ9RAZrYtMOfpO1OzONalizclpwu5G5D2ITlzU+LEX20CqbQ+iDYxC3piGRf3/ gQOR6+x4TFCGIcVlDAacv0TKiFd3qznT8SI+AbjPlMfzogPPLNNUSobPKCTS2H5lgYae UGcSmkIGdVz5M2/ugT8yz5FMJlEelwNxYJOuwUpo/FekKlnJfGvliX39i3fSEwlUPSuA MasA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=d1PBt4TCgMUHpGPAgVF3qhNY5OmS1uD9n2jgD+w8Zg0=; b=N2Vh4xPxJBFy5IkiLTNe5Ji8SvWdZtJhET5/c1fzTXRorBgxDXqLzVfh5Y/jGfOKCV Pl+akmFu4QCi0j3y/eXqeNoiF0/WYuW6iDgULCsKFwVD+NP2fu+dVb0Os9qL3xNKRRvK j2ItvSzklXSD3HSIBYTeB8TMPfccnWgpIsRnmFyVMT/+TFyEQLfvE1o+0ZTYfLY92WrQ vxDZbafVfiF2pvnx7ZjYQ3mIYbrLGQPE2+ssxZPQCyI0wY4hUmgB4xkjyD5WmriVsMO+ bD/aMZJoWFRGIh1H2fvf3I1Q/lmYymHyvlLSAfHcEu+xodjv6Oe37BKEyW8hp1sh6KsD +4hA==
MIME-Version: 1.0
X-Received: by 10.50.13.208 with SMTP id j16mr84558igc.73.1364591723793; Fri, 29 Mar 2013 14:15:23 -0700 (PDT)
Received: by 10.64.35.113 with HTTP; Fri, 29 Mar 2013 14:15:23 -0700 (PDT)
In-Reply-To: <CAOe4UikGpuy_m000z+9_yGVo=SXZ7k29y-2Vp2Cc7UXd223cKw@mail.gmail.com>
References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <CAGZ8ZG1HsW_SgB4OFRDPZT_3rUwsB8yvYxtE+fSpwLfoyrtHyg@mail.gmail.com> <CAOe4Ui=1ADLZsHrHpFofQW48DpERfAENH0a5zUFta81PejCNUA@mail.gmail.com> <C9FEEDC3-3178-4641-B9D2-6319183AD956@checkpoint.com> <CAOuvq21ZjAD3W7RmSLO0OtrE0SZ35nfw_+o+RiaOkxGS6ay0mQ@mail.gmail.com> <CAOe4UikHTm=NnDQbB-W3APrGn+MVwQLdf=j3FNsDEDNvna9yng@mail.gmail.com> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> <CAOe4UikGpuy_m000z+9_yGVo=SXZ7k29y-2Vp2Cc7UXd223cKw@mail.gmail.com>
Date: Fri, 29 Mar 2013 14:15:23 -0700
Message-ID: <CACvaWvYA1XiY12xrQA68n7Xca6OHxgN0FwOoLuggMvM8fEbYjQ@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Joseph Bonneau <jbonneau@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl8SifmoVKXWkP7LQAha8TBFSLGz0TeP6Yx1eP/8iDTRlhwkLMS6CmQjSajSclaryhS/KQwhdkH/opoOdaK78j4iDUr0xoPDSJQyQrVrwxm3DKd0pbtAfE7nAdATuoWxNvs9rkr+YZXmh53TzlciKjnZW6LnqZKqE0oUf7qDAXazCvBNDsVHQAeeZTtJ9dfWnpYhU+x
X-Mailman-Approved-At: Fri, 29 Mar 2013 19:39:39 -0700
Cc: "<websec@ietf.org>" <websec@ietf.org>, websec issue tracker <trac+websec@grenache.tools.ietf.org>
Subject: Re: [websec] #57: Re-add an upper limit to max-age
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: Fri, 29 Mar 2013 21:15:36 -0000

On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau <jbonneau@gmail.com> wrote:
>> Hopefully, it's not just Google that implements this. I guess any browser that implements this will have some kind of reset button (like they have for other stuff) that will erase all pins. So the site is not really bricked, but still it's pretty embarrassing to have to have a message on their home page like "Chrome for Mac OS X users of foo.com, due to an administrative error, please select the 'Clear Browsing Data…' menu item from the Chrome menu, select 'the beginning of time' from the dropdown menu, and check the 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry for the inconvenience."
>
> Perhaps we have a different working definition of "bricked"? By
> bricked, I meant that HPKP pins were set which the site no longer has
> the ability to satisfy, period. There are many ways that this could
> happen-pinning to two end-entity keys and losing the private keys,
> attempting to pin to a CA key but entering the hash incorrectly, and
> still having the pins accepted since the end-entity key pin is valid,
> or a malicious bricking with a mis-issued certificate. In this case, a
> bricked domain would be unable to show anything at all to users, so
> they couldn't ask users to hit a "reset pins" button as you suggest.
> Some users might figure it out through an alternate channel like
> Googling "why is foo.com down??", but it would be awful to train users
> to ever follow advice to nuke their local state like that.

So, certainly, as discussed during past meetings, and similar to the
discussions of HSTS, HPKP represents potential privacy bits being
disclosed to an attacker ("Have you been here before, and if so,
when/under what keys?"). As such, it's natural to assume/expect that
browsers will have a way to clear received dynamic pins, as part of
the normal clearing of privacy state-related data.

However, sites / site operators encouraging users to do so would be
bad for users' security - it would essentially flush their pins,
allowing potentially misissued certs to be used. If I was a 'clever'
attacker, and I had the ability to display such messages, then in the
face of being unable to attack a pinned site, I would look for a
popular-but-not-pinned site and deliberately inject bad pins (DoS'ing
the site from the users' perspective), along with some sort of message
of "Hey, clear your pins for this site to work"

Once the user cleared their pins, I would be able to attack the target
site, which would now be unpinned.

Alternative models (such as temporarily ignoring pins) sort of flies
in the face of our experiences with HSTS and the general
browser/usability issues with bypassing warnings. Clearing on a
per-site basis is the same as a bypass mode, and then we're just
talking about the number of clicks to get there - also a poor security
experience.

>
>>> If there were a max-age of 60 days, would the Chrome team take a hard
>>> line of "Sorry foo.com, you'll just have to wait it out"? Or would
>>> they ship a patch to disables HPKP for foo.com, fearing that otherwise
>>> some users will just switch to another browser to regain access?
>>
>> I don't think any of us like the answer, but this probably depends on who 'foo' is. You don't brick Gmail, Hotmail, Paypal, or any major bank in the US.  http://www.brambleberry.com ? I don't see any of the major browser issuing a patch to bail them out.
>
> I'm can live with that answer, though I'd be curious to hear from the
> Chrome developers (who are likely to be the pioneers here). If a
> channel to whitelist misconfigured HPKP domains is going to be built,
> it changes the discussion around max-age limits to be mostly a
> performance optimization and I don't think it's a good security
> tradeoff.

I don't have any answer for this at this time. There are obviously a
set of security trade-offs here.

Do you trust/want your browser vendor to deliver secure pins (aka
pre-loaded pins)?
Do you trust/want your browser vendor to deliver unpins (of dynamic pins)?

The risks and likely responses to the first question are very
different than those of the second.