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

From: "websec issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 21:36:03 -0000

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

 At IETF 86, it was decided that there should be an upper limit to the max-
 age directive

-- 
--------------------------------+-------------------------------
 Reporter:  [email-masked]   |      Owner:  [email-masked]
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:
Component:  key-pinning         |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+-------------------------------

Ticket URL: <http://tools.ietf.org/wg/websec/trac/ticket/57>
websec <http://tools.ietf.org/websec/>

---

From: "websec issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 21:39:55 -0000

Comment (by [email-masked]):

 Rather, it was decided that there should be implementation guidance for
 setting an upper limit, including discussing the security considerations
 /trade-offs of high vs. low maximum max-age values.

-- 
--------------------------------+--------------------------------
 Reporter:  [email-masked]   |       Owner:  [email-masked]
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:
Component:  key-pinning         |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/57#comment:1>
websec <http://tools.ietf.org/websec/>

---

From: "websec issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 22:16:17 -0000

I have added language discussing the issue to the latest working copy of
 the draft at https://code.google.com/p/key-pinning-draft/source/browse
 /draft-ietf-websec-key-pinning.xml.

Ticket URL: <http://tools.ietf.org/wg/websec/trac/ticket/57#comment:2>
websec <http://tools.ietf.org/websec/>

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 22 Mar 2013 16:07:36 -0700

>  /trade-offs of high vs. low maximum max-age values.

So this maximum is a "local policy" decided by the UA?

It might be good to also have a spec-mandated maximum.

There are cases where you (a domain owner) might have unknown pins or
bad pins.  For example:
 - you purchased a domain name from someone
 - the domain name was victimized by domain hijacking or domain squatting
 - you misconfigured pins for your domain

If there's no spec-mandated maximum, then there's no point in time at
which all old pins are guaranteed to have been expired, and you can
start referring people to this domain safely.

With a spec maximum (say 30 days), then you have a clear reference
point to plan around.

Trevor

---

From: Joseph Bonneau <[email-masked]>
Date: Fri, 22 Mar 2013 19:36:19 -0400

> With a spec maximum (say 30 days), then you have a clear reference

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).

These are only a rough upper bound on the max-age values that would be
set for pins, but it seems a substantial number of hosts would request
longer than 30 days, while 1 year will support most likely use cases,
so we should probably land somewhere between those two points.

The follow-on question is, if UAs allow max-age of 1 year, will there
need to be a revocation method to deal with some of the cases that
Trevor highlighted?

---

From: Yoav Nir <[email-masked]>
Date: Sat, 23 Mar 2013 02:13:18 +0000

> 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.

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.

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. 

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?

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 23 Mar 2013 20:37:48 +0800

<hat="individual">
I agree with Yoav's comment.

Am not 100% sure on this, as I don't know the frequency of
"self-bricking" due to the reasons described by Trevor, but feel that 30
days is too short for protection of rare use users. Don't forget, we
have not solved the boot-strapping issue for HSTS and HKPK. So if the
max-age is too low, we basically leave all infrequent users unprotected.
(and I guess there are quite a number of important sites that people
would only go to only once in a while but not for sure every 30 days).

If I would have to balance between "self-inflicted bricking" (due to
mis-config, bad business deals, weak security, etc.) and user
protection, my vote would go for user protection.

So if we need a max-age, I would probably prefer a longer time, e.g. a
max-age of 1 year.

Best regards, Tobias

On 23/03/13 10:13, Yoav Nir wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 23 Mar 2013 15:19:30 -0700

> 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…

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
continuity.

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
them).
 * "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".

Trevor

---

From: Chris Palmer <[email-masked]>
Date: Wed, 27 Mar 2013 15:43:21 -0700

> 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 EC…

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…

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.

---

From: Joseph Bonneau <[email-masked]>
Date: Wed, 27 Mar 2013 19:16:24 -0400

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

To me, the question isn't so much about how long sites will want to
set max-age for, it's "How long would HPKP-browser makers allow a
domain to be bricked before caving to pressure to add it to some
whitelist/revocation list?" I think it's inevitable that some foo.com
*will* brick themselves using HPKP (or possibly be bricked
maliciously) and then come crawling to Chrome (or other implementing
browsers) asking to be bailed out.

If there were a max-age of 60 days, would the Chrome team take a hard
line of "Sorry foo.com, you'll just have to wait it out"? Or would
they ship a patch to disables HPKP for foo.com, fearing that otherwise
some users will just switch to another browser to regain access?

If the former is more likely, then a max max-age of 60 days is
reasonable. If the latter is more likely, then I'd argue against
having a max max-age at all and instead plan to deal with failures in
a deus ex machina way.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Mar 2013 01:33:01 +0000

> browsers) asking to be bailed out.

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."

> 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.  http://www.brambleberry.com ? I don't see any of the major browser issuing a patch to bail them out.

---

From: Joseph Bonneau <[email-masked]>
Date: Fri, 29 Mar 2013 13:45:36 -0400

> 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…

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

> 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.  http://www.brambleberry.com ? I don't see a…

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
tradeoff.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Mar 2013 21:15:44 +0000

> 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.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 30 Mar 2013 02:05:18 +0000

On Mar 29, 2013, at 5:15 PM, Ryan Sleevi <[email-masked]> wrote:

> On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau <[email-masked]> wrote:
> So, certainly, as discussed during past meetings, and similar to the
> discussions of HSTS, HPKP represents potential privacy bits being
> disclosed to an attacker ("Have you been here before, and if so,
> when/under what keys?"). As such, it's natural to assume/expect that
> browsers will have a way to clear received dynamic pins, as part of
> the normal clearing of privacy state-related data.
> 
> However, sites / site operators encouraging users to do so would be
> bad for users' security - it would essentially flush their pins,
> allowing potentially misissued certs to be used. If I was a 'clever'
> attacker, and I had the ability to display such messages, then in the
> face of being unable to attack a pinned site, I would look for a
> popular-but-not-pinned site and deliberately inject bad pins (DoS'ing
> the site from the users' perspective), along with some sort of message
> of "Hey, clear your pins for this site to work"
> 
> Once the user cleared their pins, I would be able to attack the target
> site, which would now be unpinned.
> 
> Alternative models (such as temporarily ignoring pins) sort of flies
> in the face of our experiences with HSTS and the general
> browser/usability issues with bypassing warnings. Clearing on a
> per-site basis is the same as a bypass mode, and then we're just
> talking about the number of clicks to get there - also a poor security
> experience.

All true, but if I want to delete my pins, I will, even if I have to search the Internet (using Google, of course) for how to edit the pins on Chrome. I only hope that instructing your users to do this will be enough of a "doghouse" for site operators. As it is, expired certs and chains that don't chain are becoming more and more rare. The power of embarrassment seems to be working there, even though there is a click-through option.

Getting back to the subject of the thread, I still don't see the difference for a site operator between being bricked for 60 days and being bricked for a year. For an only retailer it's catastrophe either way.

Yoav

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 29 Mar 2013 14:15:23 -0700

> performance optimization and I don't think it's a good security

I don't have any answer for this at this time. There are obviously a
set of security trade-offs here.

Do you trust/want your browser vendor to deliver secure pins (aka
pre-loaded pins)?
Do you trust/want your browser vendor to deliver unpins (of dynamic pins)?

The risks and likely responses to the first question are very
different than those of the second.