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

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 00:03:10 -0700

On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir <[email-masked]> wrote:
>
> 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.

Hi Yoav,

There are other things to consider when thinking about pin lifetimes:

 - Suppose a site foolishly sets a year-long pin to keys that will be
expired in 6 months.  A client who receives this pin and then visits
the site 6 months later will perceive that the site is bricked for the
next 6 months.

 - Suppose a site has a year-long pin to a set of end-entity keys.
Suppose these keys are compromised by a hacker.  For the next year,
the site will be unable to change keys to re-establish security
without a risk of "bricking" the site for clients with the old pin.

 - Suppose you purchase a domain name.  The previous owner may have
set long-term pins, meaning the name is not fully usable until these
expire.

So this isn't just a question of "how long might a site outage last".
Longer pin lifetimes increase the *possibility* of a site outage,
because there will be more old pins out there you have to stay
consistent with.

I do agree that a 30 or 60 day limit will be cold comfort if you brick
your site for that long.  Certainly, pinning will need other
safeguards.

One safeguard could be some sort of "pin activation", where new or
changed pins are not accepted immediately, but must be observed for
some period of time before they "activate".  I know this WG considered
a mechanism similar to TACK.  TACK's exact mechanism doesn't translate
well to HPKP, but perhaps there is something else to be done.  It may
be worth more thought.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Fri, 5 Apr 2013 08:48:11 +0000

> the site 6 months later will perceive that the site is bricked for the

True. At least in the case of certificates, there was some discussion of capping the maximum noted age to the expiration time of the certificate for that connection. This is not a complete solution, though, because there is some period of time (perhaps 1-2 weeks) where the site operator has a new, valid certificate, but the old one hasn't expired yet.

A backup pin should work, as I believe the common practice would be to use the backup pin in the following certificate request. And backup pins are mandatory according to the draft.

> without a risk of "bricking" the site for clients with the old pin.

And that is why the draft now requires backup pins. At least, it's one reason.

> set long-term pins, meaning the name is not fully usable until these

Yeah, that's bad. Even worse is if an attacker manages to get a CA to issue them a valid certificate. Users now note pins that match the bad certificate, and they can be blocked from going to the real site for some time. HPKP protects against exactly this attack, but it only does so for sites that publish pins, and for users who have noted pins. If I get a new computer/browser/phone during the attack, I (and some others) will note the attacker's pin.

> well to HPKP, but perhaps there is something else to be done.  It may

I think it's clear that HPKP (much like HSTS) is a gun with which site operators can easily shoot themselves (or their users) in the foot. There has to be a certain level of competence and responsibility to make use of these mechanisms. They should not be used lightly. OTOH I don't think we should bind the hands of administrators who do choose to use it.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 09:53:38 -0700

> True. At least in the case of certificates, there was some discussion of capping the maximum noted age to the expiration time of the certificate for that connection. This is not a complete solution…

That also means that if a site uses short-lived or soon-to-expire
certificates the pin lifetime could get badly truncated, so that's not
a great idea.

Anyways, expiration is just one way the above problem could happen.
Imagine that you mistakenly set a year-long pin to CA keys that your
CA is going to roll / phase-out in 6 months.  Same problem.  Capping
pin lifetimes means less risk of this occurring.

> A backup pin should work, as I believe the common practice would be to use the backup pin in the following certificate request. And backup pins are mandatory according to the draft.

Backup pin don't solve this problem.  Backup keys can be revoked /
expired / rolled / lost like other keys.

> And that is why the draft now requires backup pins. At least, it's one reason.

No, I'm describing the scenario where ALL your pinned keys, including
"backup pins", were compromised.  Maybe you were keeping all your
pinned end-entity keys in an offline laptop which was stolen.  Maybe
you were pinning yourself exclusively to CAs operated by a single
commercial entity (e.g. Symantec), and you lose trust in this entity.

In these scenarios, you are "locked-in" and prevented from key changes
during the pin lifetime.

> Yeah, that's bad. Even worse is if an attacker manages to get a CA to issue them a valid certificate. Users now note pins that match the bad certificate, and they can be blocked from going to the real site for some time.

Yes that's what I'm describing.

> HPKP protects against exactly this attack

No, HPKP or any dynamic-pinning method *CAUSES* this attack, by
allowing the previous owner of any domain name to acquire a
certificate, then use it to set pins.

> I think it's clear that HPKP (much like HSTS) is a gun with which site operators can easily shoot themselves (or their users) in the foot.

The risks and issues around key-pinning lifetimes are completely
different from HSTS.  HSTS cannot make it impossible for a site to be
reached, or lock you into insecure keys.

> There has to be a certain level of competence and responsibility to make use of these mechanisms. They should not be used lightly.

Please note that dynamic pinning creates risks for the entire web by
virtue of existing.  If 1/1000 websites "opt-in" to a key pinning
mechanism, the remaining 999 are still exposed to the risk that their
DNS name could be hijacked and a bad pin could be set.

And anyone who purchases or acquires a domain name is still exposed to
the risk that it could come with an unpleasant "pinning" surprise.

>OTOH I don't think we should bind the hands of administrators who do choose to use it.

Long-lived pins are *more* likely to bind the hands of administrators
than short-lived, which is why I think pin lifetimes should be
strictly limited.

Trevor