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

Chris Palmer <> Wed, 27 March 2013 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34A5721F9047 for <>; Wed, 27 Mar 2013 15:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NRgDUx1UvqrQ for <>; Wed, 27 Mar 2013 15:43:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2430421F87F5 for <>; Wed, 27 Mar 2013 15:43:22 -0700 (PDT)
Received: by with SMTP id hv10so6875963vcb.26 for <>; Wed, 27 Mar 2013 15:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=iw1HigbpAukTgAOvw/aW6QsEi0/nNFR0Aan1x81eHbY=; b=AoAkTiP9y9dOFxcqgJpg33nE9To7V/BfPXNh6evZgmQYk3slYfZ7A02ztW8skuMGyA EXUNYgN4rkS2rPuXMbn6+I+a5uKQjQ7t6mkm5q9qQsY6pPWew4Go9c9dhaQ78m0aBzby nk3T1the+Kuk8kDjqYEySG/7AtpCt2mTl0E6G3tLXK1Q7WsH9wiBr8XSEb0+a+oAQ8Vs 4T/IPGH+tu6EyGH89RXtFZqtNVAKBqwHG1ftTPggh6FrC4fLVFXEZSb4AtEBj7BKB/o2 dHboNRbGJGzHtYuLlansVeFRmpZKcX8nO0lkE8mgCfMS0mXdC5UlThsgsit3lEPkFB5b 9oxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=iw1HigbpAukTgAOvw/aW6QsEi0/nNFR0Aan1x81eHbY=; b=IM/HW9s6H3TCx3fvxOvvjHPQHGyhIJ+SOaR2YVxB0zBJUOH2K3pMDupsupa69XcDIt +U5apbKsO5naLSDlgn45WBOBFeotgT2VjbCxTsv+Bt0vv3lszWTMGVxmRX2ZBVsuy0jG ZvpIQ81n9WJCaVbs0iEh5bwBx+Ut22mCCdtDmIN88mB+wjqLblb+IhhkrIytSFQR4GRe 2SH0mx0Mcaa5HtamC/bT2r3/2Rnzk7tMOW3Xhm1w6PwyvAuqtA4dxb/1VOpGWa0hp/2b M6r79Ve5ETiWr5Yn39aNhMRtktDE6aPHzE4K0f3Zh6wF6vpSqPefpRCRwl3EEjGy5pmR ZEWQ==
MIME-Version: 1.0
X-Received: by with SMTP id c1mr4393916vck.48.1364424201510; Wed, 27 Mar 2013 15:43:21 -0700 (PDT)
Received: by with HTTP; Wed, 27 Mar 2013 15:43:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 27 Mar 2013 15:43:21 -0700
Message-ID: <>
From: Chris Palmer <>
To: Yoav Nir <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnIG+BkQcDhLBDL9Yqxgd9zyJWrMIKRAFH77LzSf2I+LVK3ASo+MMUe7yMGcZ9nnzVLMs0MawL9WX0PS2sjHs3MLFXIETEKK03gfZeLjWCOTZWlvZu88DVQM02v/8oyRZuPdnY5jwveyWtZrl/xYR2iq19Mscz090OhOoETKGh1i6PdMZYuIFVKARfZ550YR6aGq+Bb
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: Wed, 27 Mar 2013 22:43:26 -0000

On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir <> wrote:

> OTOH a particular public key might be replaced because of switching certificate vendors, because auditors don't like that key length any more, or because your certificate vendor has decided that ECC is the way to go. Pinning something that has an expiry date for an unlimited time could be a problem.

If you have a planned pin set transition (new issuer, new key type, et
c.), you can (and should!) update your PKP header to include the new
pins weeks in advance of the actual transition. The UA MUST store the
new pins (assuming your PKP header meets the requirements of a Valid
Pinning Header, of course), and when you later make the deployment
change, UAs will know about your new keys and Pin Validation will

You might also choose to lower your max-age during a time of
transition, too; you might choose to bump it back up when going back
into a steady state.

You should also set your max-age to be in harmony with your deployment
plans, of course. Depending on your needs, your max-age might be short
indeed. Especially at the beginning of your deployment of HPKP, it's
probably wise to set a low max-age until you are more certain how it's
going to work out for your site.

> 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. If either the draft or the UA sets an upper limit of 30 days, then HKPK won't work for This is a site that I only use from one week before an IETF meeting to one week following it. In between there are a little over three months where I don't use the site at all. So it would make sense for the site operator to set a max-age of 4 months. That limit may be inappropriate for web mail or social media, but even those might be accessed from different UAs at different times. For example, I might use my home computer for a social media site while I'm at home, but use a smart phone or a laptop for the same site when I'm away from home.

Yes, I discuss this trade-off in Security Considerations (in the
working copy of the draft). I tend to agree with Trevor Perrin when he
says, """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"."""

So, 30 days, or 60 days, we can argue about. But 1 year might be too
long a time — if we decide to have a mandated max max-age, instead of
just providing UA implementation advice.

Is there consensus that we should mandate a max max-age, or consensus
that we should not?

FWIW, currently Google Chrome sets a limit of 10 weeks for the
pre-loaded pin list. If you haven't gotten a fresh update of Chrome
(which contains the preloaded pins, baked in), then something is wrong
and we fail open so that you can recover.

Please consider that HPKP is not intended to be "perfect"; it has to
work for the internet at large in a variety of site deployment and
usage scenarios. It may very well be that it works better for sites
that people visit every day or every week than for sites that you
visit once per quarter. If Twitter can make use of it but
cannot, that's still a net win even if not a perfect win.