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

[Chris Palmer <[e-mail]>]

On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir <[e-mail]> 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
pass.

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 pub.ietf.org. 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 pub.ietf.org
cannot, that's still a net win even if not a perfect win.