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

[websec issue tracker]

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

Changes (by pal...@google.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The new language satisfies the rough consensus in the WG.

-- 
+
 Reporter:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  closed
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Trevor Perrin]

On Fri, Apr 5, 2013 at 1:48 AM, Yoav Nir  wrote:
>
> On Apr 5, 2013, at 10:03 AM, Trevor Perrin  wrote:
>
>> On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir  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.
>
> 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.

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.


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


>> - 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.
>
> 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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Yoav Nir]

On Apr 5, 2013, at 10:03 AM, Trevor Perrin  wrote:

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

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.

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

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

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

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.

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

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


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Trevor Perrin]

On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir  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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Ryan Sleevi]

On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau  wrote:
>> 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."
>
> 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.

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.

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

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.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Yoav Nir]

On Mar 29, 2013, at 5:15 PM, Ryan Sleevi  wrote:

> On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau  wrote:
>>> 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."
>> 
>> 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.
> 
> 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

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Yoav Nir]

On Mar 29, 2013, at 1:45 PM, Joseph Bonneau  wrote:

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

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.

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Joseph Bonneau]

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

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.

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

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.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Yoav Nir]

On Mar 27, 2013, at 7:16 PM, Joseph Bonneau 
 wrote:

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

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

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

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.

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

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Joseph Bonneau]

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

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.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Chris Palmer]

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
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.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Trevor Perrin]

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
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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tobias Gondrom]

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:
> 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.
>
> 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
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Yoav Nir]

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.

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

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Joseph Bonneau]

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

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?
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Trevor Perrin]

On Fri, Mar 22, 2013 at 2:39 PM, websec issue tracker
 wrote:
> #57: Re-add an upper limit to max-age
>
>
> Comment (by pal...@google.com):
>
>  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.

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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[websec issue tracker]

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


Comment (by pal...@google.com):

 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.

-- 
+
 Reporter:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[websec issue tracker]

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


Comment (by pal...@google.com):

 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:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[websec issue tracker]

#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:  pal...@google.com   |  Owner:  pal...@google.com
 Type:  defect  | Status:  new
 Priority:  major   |  Milestone:
Component:  key-pinning |Version:
 Severity:  Active WG Document  |   Keywords:
+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec