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

Trevor Perrin <> Sat, 23 March 2013 22:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0BBA21F8BDD for <>; Sat, 23 Mar 2013 15:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hysI-1m2IiGR for <>; Sat, 23 Mar 2013 15:19:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) by (Postfix) with ESMTP id E0F5C21F8BDB for <>; Sat, 23 Mar 2013 15:19:31 -0700 (PDT)
Received: by with SMTP id ez12so885725wid.6 for <>; Sat, 23 Mar 2013 15:19:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=RsF0Rx459zwlQiHXk46NvX4E9GdfJ36RUyugifS5Hbk=; b=ffDZb4Q2p9AvKuHuia6Nu/VxE+/7KNW7mMtquI+TY8WXoS45p7VzCevpX3/fomTNDH eg2xFbzw+ybk7kh4cPf4OeuTTsmZSlOUhXkBW5r3gsML0MFycwo+1uE9ORGjQU5WmcF9 MXlSg6QVbZK3qDHk5ONJyOYj/0Cq+OMjpVT8cIk151bx6kkZoJdMOmzfqvd5PC+78FDE Z6eZ+GfGZm/eREebG6VthTf523N2IO9F1SDIDIrgY2XkXlOjA+lFCoebiAXazMahsHWL q48MlBbWbYNoy0koL5zzuqt8uXpk+kwyoX4jk/iETQkygOyypnnC0IG8v7fICPo2UxiX /yDw==
MIME-Version: 1.0
X-Received: by with SMTP id f2mr10258663wjy.25.1364077170950; Sat, 23 Mar 2013 15:19:30 -0700 (PDT)
Received: by with HTTP; Sat, 23 Mar 2013 15:19:30 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sat, 23 Mar 2013 15:19:30 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Yoav Nir <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmKc3PTWT+oBk+Efizq7K+t4crsmta6xdU6G8l9e/xYTQ6VBnqd6Mbl/Yjxgzr6MZfOcLBh
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: Sat, 23 Mar 2013 22:19:33 -0000

On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir <> wrote:
> On Mar 22, 2013, at 7:36 PM, Joseph Bonneau <> wrote:
>> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin <> wrote:
>>> With a spec maximum (say 30 days), then you have a clear reference
>>> point to plan around.
>> Agreed.
>> I have some stats I've been looking at from Google's web crawls about
>> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a
>> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1
>> day, and a smattering of other choices (with a few large hosts like
>> Twitter setting very long-lived max-age).
> As Ekr said in the meeting, there is a big difference here between HSTS and HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a million years. It's not likely that someone who has declared a policy for always using secure transport will suddenly switch to non-secure transport. They might stop advertising HSTS, but they're not likely to stop insisting on TLS use.

Hi Yoav,

Agreed that the issues around "pin lifetimes" are very different for
HSTS and key pinning.

If HSTS get mistakenly or maliciously set for your domain, it's no big
deal.  You just deploy SSL.

If your domain gets pinned to keys you don't control, it's a big problem.

> Something to consider is that if the max-age time is shorter than the time between accesses to the site, the security of this mechanism is lost.

I agree we'd like more security than a 30-day browser-side "key
continuity" window.

This is perhaps controversial, but I'd hope we could get that
additional security *without* cranking up pin lifetimes, by
considering ways to use pinning beyond just browser-side key

For example:
 * Web crawlers could build pin lists for all sites they observe.
 * Browsers could periodically download a subset of these pin lists
(for the most popular sites, or for communities of sites relevant to
 * "Trusted introducers" such as search engines could embed pins from
a pin list into "secure links" that they serve.
 * Browsers could do online lookups to a pin list (whether blocking a
la Convergence or after-the-fact a la Certificate Transparency).

These ideas are all enabled or enhanced by key pinning, but they don't
require long pin lifetimes.  They just require pin lifetimes large
enough that recrawling / redownloading pin lists / clearing caches
etc. doesn't have to be done too frequently.

> I understand Trevor's issue. Does it make a difference to a site operator whether the site is partially bricked by bad pins for 30 days or 365 days?

Consider cybersquatting or a domain name dispute, where someone loses
control of a domain to its new (rightful) owner.

The loser could set key pins before the domain is transferred, either
for spite or to ransom the keys to the new owner.  If the new owner
has to wait 30 days before the domain is usable, that's a bummer but
seems on the edge of tolerable.  A year would be a long time.

More generally, I think the important dictums here are:
 * First, do no harm
 * Second, don't scare users away!

The biggest risk is not that the protection window will be too short,
it's that we'll screw up the Internet, and the mechanism will be (or
will be perceived as) too dangerous to use.

So, I think it's best to push tradeoffs like this in the direction of
safe, fail-open behavior, instead of trying to squeeze out every
possible bit of "security".