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

Joseph Bonneau <> Fri, 29 March 2013 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BDD521F9159 for <>; Fri, 29 Mar 2013 10:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMaa767fy3w2 for <>; Fri, 29 Mar 2013 10:45:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6220B21F86D9 for <>; Fri, 29 Mar 2013 10:45:58 -0700 (PDT)
Received: by with SMTP id o13so45317qaj.3 for <>; Fri, 29 Mar 2013 10:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wpDte95WiResj7OpPCtcUTAwaBqrl+S0q4gNcvzewEQ=; b=nuHsp2M0WcIOMAtI0+W3fESrxnZlqnDABtdN6lXvvk99S+d2JmJp5lODXIOAQjjE5k aleWpmTkZ0nVm9zeVTrAjS3Fa781znezvTPvqs1exoJpsl+awJBCnjycGejZWlzJADqt dJ6RyQmrA9OzUqA4RzWbroGbO18bu+QQcweMg5++zBoXO/EshevUCNXP7PFFG3/d2QBq hRPSjj6yjqaP1YiCQDB7xC5H9d7cf4nTw0b5Rb+T63PyA6kus6PKT4h/GsUWVrsZ4SlA TTRaEPCkZajVO3mWX5NkrJcwsAD6nSIDdfR+5u950ikB09/tNSp3pJCYGz9XoYJT9DOy QrVg==
X-Received: by with SMTP id fr2mr1483839qcb.42.1364579157909; Fri, 29 Mar 2013 10:45:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 29 Mar 2013 10:45:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Joseph Bonneau <>
Date: Fri, 29 Mar 2013 13:45:36 -0400
Message-ID: <>
To: Yoav Nir <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>, websec issue tracker <>, "<>" <>
Subject: Re: [websec] #57: Re-add an upper limit to max-age
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2013 17:45:59 -0000

> 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, 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 down??", but it would be awful to train users
to ever follow advice to nuke their local state like that.

>> If there were a max-age of 60 days, would the Chrome team take a hard
>> line of "Sorry, you'll just have to wait it out"? Or would
>> they ship a patch to disables HPKP for, 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. ? 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