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

Yoav Nir <ynir@checkpoint.com> Fri, 29 March 2013 21:16 UTC

Return-Path: <ynir@checkpoint.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 A191721E8050 for <websec@ietfa.amsl.com>; Fri, 29 Mar 2013 14:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 mmVk1pDMBQlA for <websec@ietfa.amsl.com>; Fri, 29 Mar 2013 14:16:02 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8921E804D for <websec@ietf.org>; Fri, 29 Mar 2013 14:15:58 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2TLFj1E018827; Sat, 30 Mar 2013 00:15:45 +0300
X-CheckPoint: {515602C4-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 30 Mar 2013 00:15:45 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Joseph Bonneau <jbonneau@gmail.com>
Thread-Topic: [websec] #57: Re-add an upper limit to max-age
Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgIAHoQKAgAAJPACAAbiWgIAA/uQAgAA60gA=
Date: Fri, 29 Mar 2013 21:15:44 +0000
Message-ID: <91E15149-9991-4B98-B182-53B7CA0D3285@checkpoint.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>
In-Reply-To: <CAOe4UikGpuy_m000z+9_yGVo=SXZ7k29y-2Vp2Cc7UXd223cKw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.235]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <A905BBAD25559C4AB7974345235C8E55@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<websec@ietf.org>" <websec@ietf.org>, websec issue tracker <trac+websec@grenache.tools.ietf.org>, "<sleevi@google.com>" <sleevi@google.com>
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:16:06 -0000

On Mar 29, 2013, at 1:45 PM, 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.

This assumes all these domains are also STS (H or not). If the site also has an HTTP server (like most are now), then that server can display the message.

Perhaps there should be some website that lists bricked domains, perhaps maintained by the browser vendors or a consortium (CABF?). So when you get the HPKP error screen, you will not be able to click through, but you will be able to get the list of recently bricked domains. So if the site you were looking for is listed there, you would shake your head at their incompetence, and proceed to clear pins (or clear the specific pin if you're more security conscious). Of course, that site has to be strictly secure.