Subject: [websec] Consensus call: Issue #57 (max-max-age)

From: Yoav Nir <[email-masked]>
Date: Tue, 7 May 2013 07:13:28 +0000

Hi folks

We think it's time to move on with Key Pinning, as there haven't been substantial issues raised in months.  The one outstanding contentious issue is the one in the subject: http://trac.tools.ietf.org/wg/websec/trac/ticket/57

We've heard the argument that allowing pins to exist for indefinitely long can cause a site to be bricked for that period because of simple mistakes like changing certificate vendor or changing ownership of the domain name.

We've also heard the counter-argument that some domains are visited infrequently, so short pins would do nothing for them.

So here are some options. Please reply to this thread with with your preference. Arguments are good, but "+1" works as well. So…

How should we handle the max-max-age issue:
 (1) No hard limits, but allow UAs to limit the pin time. Suggest a month
 (2) Set a hard limit of one month in the RFC. Longer pins are truncated.
 (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month)
 (4) Adopt some gradual confidence-building scheme a-la-TACK.

"None of the above" is possible, but MUST come with argument and proposed text.

Let's give this until Wednesday, 22-May.

Thanks

Tobias & Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 8 May 2013 12:01:52 -0700

On Tue, May 7, 2013 at 12:13 AM, Yoav Nir <[email-masked]> wrote:

>  (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't
> been observed for some time (like a month)

Hi Yoav,

I suggest this could be viewed as two separate questions:

 A) Should there be / what is the spec-mandated max pin lifetime?
   - (this is your 1/2/3)

 B) How are pin lifetimes set?
   - server assertion ("max-age")
   - confidence building (eg "pin activation")
   - some combination?  something else?

These questions are somewhat independent: you could have a spec-mandated
max regardless of whether pin lifetimes are set from server assertions *or*
confidence-building.

Anyways, the first question has been discussed a bunch, and I think it's
reasonable to try to get a consensus.  My vote is #2, with "30 days".

The second question hasn't been discussed much, and has some complexity.
 Maybe we should try to encourage more discussion / research of the
options, before trying to pull out a consensus?

Trevor

---

From: Tom Ritter <[email-masked]>
Date: Sat, 11 May 2013 16:09:52 -0400

> "None of the above" is possible, but MUST come with argument and proposed text.

None of the above:  No hard limits, leave limiting the pin time
unspecified, make no suggestion.  I don't believe any text changes are
necessary.

I think UAs that are sufficiently worried about websites bricking
themselves come up with creative solutions that work well for them,
but may not be applicable to others.  (Chrome's will (or would) expire
hardcoded pins if there hasn't been a Chrome update in a month - they
could do the same for max-ages.)  I don't like the idea of suggesting
that UAs unilaterally override a site's possible desire to pin for
more than 1 month.

-tom.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 May 2013 09:40:48 +0900

I agree with Tom Ritter, with one caveat: The spec should very clearly 
call out the issue (balance between too soon pin expiry and too long), 
rather than not mentioning it. I haven't found such language (i.e. 
guidance to UA implementers) in the document, but I might have looked in 
the wrong place (I looked at every piece of text that contained the 
three letters 'max').

Regards,   Martin.

On 2013/05/12 5:09, Tom Ritter wrote:
> On 7 May 2013 03:13, Yoav Nir<[email-masked]>  wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 May 2013 11:57:09 +0000

Hi Martin

Such guidance in the spec is relevant for the rightful domain owners. Suppose an attacker got some CA to issue a bad certificate for facebook.com. The attacker now sets up this certificate on some public proxy, and sets a pin for 20 years. Within days the attack is discovered, the certificate revoked and the fake website taken down. But the user-agents that received this pin are blocked from reaching facebook. A limit would help by getting them off of facebook for just 1 month.

Also, if a domain name is sold or transferred to another entity, a long-lived pin could mean that the new owner can't put a website there.

I'm not saying these are compelling arguments to limit pins in the UA, but they should be considered.

Yoav

On May 12, 2013, at 3:40 AM, Martin J. Dürst <[email-masked]> wrote:

> I agree with Tom Ritter, with one caveat: The spec should very clearly call out the issue (balance between too soon pin expiry and too long), rather than not mentioning it. I haven't found such language (i.e. guidance to UA implementers) in the document, but I might have looked in the wrong place (I looked at every piece of text that contained the three letters 'max').
> 
> Regards,   Martin.
>

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 16 May 2013 08:53:43 +0100

<hat="individual">

I agree with Tom.

Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 16 May 2013 08:58:02 +0100

<hat="individual">

Hi all,

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

And regarding some of the concerns of pro-longed malicious bricking by
an attacker after an attack has been resolved:
Two scenarios:
1. I believe if we have a time limit of more than 1 month we need a
different mechanism (e.g. user actively flushing the key cache) anyway.
2. in the case of high frequency sites (like you mentioned Facebook),
imagine even a 1 month brick time would already be considered
unacceptable too long by most users (in fact probably everything above a
few hours would be considered too long) and trigger user action to flush
the cache.

Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 18 May 2013 10:40:42 -0700

Hi Tobias, all,

I think Tobias gives a fair summary of the arguments against a 30-day spec
limit.  Let me summarize the opposing arguments:

On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom <[email-masked]
> wrote:

> regularly expire before people return to the site and the protection is

You're assuming that pin assertions (like HPKP headers) are only processed
by individual browsers.

I hope pin assertions will *also* be processed by web crawlers to create
pin lists which are made available to browsers (via preloaded lists, secure
links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the
frequency of re-crawling sites and re-downloading pin lists manageable.
 Longer pins wouldn't be a big improvement.

> few hours would be considered too long) and trigger user action to flush

Agreed that a 30-day limit is not, by itself, sufficient mitigation against
"malicious bricking by an attacker after an attack".  I suspect pinning
will need several additional mechanisms to prevent, limit, and recover from
such attacks.  "Pin activation" is one mechanism I think is particularly
helpful, for this case.

A 30-day spec limit is more important for other reasons:
 1) Domain name transfers (sales, disputes, reclaiming hijacked domains,
etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA keys which you
lose trust in and suspect might be participating in MITM attacks; you are
not bricked, but you are unable to change to a different CA and assert new
CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site consistent
with (Do you remember what pins you or the previous domain owner asserted 6
month ago? 6 years ago? ever?  They might still be out there, waiting to
trip you up).

In each of these cases, the site has a decision to make:
 1) When can the site start using its new domain name?
 2) When can the site change pinned keys?
 3) What certificate chains are consistent with extant pins?

Having a mandated 30-day limit makes these questions easier:
 1) The site can always use a new domain name 30 days after acquiring it.
 2) The site can always change pinned keys 30 days after last asserting the
pin.
 3) The site only has to consider pin assertions from the last 30 days.

If browsers can take "creative" approaches to pin limits, per Tom Ritter
[1], it's harder for sites to make these decisions.  Sites would need to
know what algorithms / parameters every browser is using and has used in
the past.  And if some browsers made bad decisions and store excessively
long pins, the site will have to decide whether it's OK to make changes
even if some users will have problems.

Anyways, I think making things safe and simple for site operators is more
important than browser creativity, or trying to maximize pinning's security
benefits.  That's why I still prefer a spec-mandated limit.  And I think 30
days strikes a good balance between security benefits and safety, and is
easy to remember and explain.

Trevor

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01597.html

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 May 2013 22:26:14 +0000

Hi Trevor

<no hats>

The suggestion that web spiders also note pins is interesting, but it's not mentioned in the draft at all. So I believe that we have to take the draft at face value, that it is user agents that are supposed to note pins. BTW: assuming that relatively few sites have pins, it is also possible for the browser itself to load pages in the background to refresh the list of pins. Either way, we have to assume that the pin is noted by a user agent and is noted again only when the user clicks a link or types in the address again. I don't think we want to require anything else.

I do agree that a spider or the browser itself can periodically check on pins.

You go on to note three cases where limiting the max-age may be beneficial:
 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever?  They might still be out there, waiting to trip you up).

#2 and #3 make sense, but they only make sense as reasons to set max-age to a relatively short value. It may be good to incorporate this as advice to the administrator as to what to set max-age to. They are not a good reason, IMO, to set a hard limit in the protocol.

So we're left with #1. And I would add to that the case where an attacker managed to get a valid-looking certificate for the domain (as in the diginotar case), and used the session to set a false pin with a long max-age.

I agree that there's an issue here. I just think that it should be balanced against the needs of infrequently accessed domains.

Yoav

On May 18, 2013, at 8:40 PM, Trevor Perrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tobias, all,

I think Tobias gives a fair summary of the arguments against a 30-day spec limit.  Let me summarize the opposing arguments:

On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

You're assuming that pin assertions (like HPKP headers) are only processed by individual browsers.

I hope pin assertions will *also* be processed by web crawlers to create pin lists which are made available to browsers (via preloaded lists, secure links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the frequency of re-crawling sites and re-downloading pin lists manageable.  Longer pins wouldn't be a big improvement.

Agreed that a 30-day limit is not, by itself, sufficient mitigation against "malicious bricking by an attacker after an attack".  I suspect pinning will need several additional mechanisms to prevent, limit, and recover from such attacks.  "Pin activation" is one mechanism I think is particularly helpful, for this case.

A 30-day spec limit is more important for other reasons:
 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever?  They might still be out there, waiting to trip you up).

Having a mandated 30-day limit makes these questions easier:
 1) The site can always use a new domain name 30 days after acquiring it.
 2) The site can always change pinned keys 30 days after last asserting the pin.
 3) The site only has to consider pin assertions from the last 30 days.

If browsers can take "creative" approaches to pin limits, per Tom Ritter [1], it's harder for sites to make these decisions.  Sites would need to know what algorithms / parameters every browser is using and has used in the past.  And if some browsers made bad decisions and store excessively long pins, the site will have to decide whether it's OK to make changes even if some users will have problems.

Anyways, I think making things safe and simple for site operators is more important than browser creativity, or trying to maximize pinning's security benefits.  That's why I still prefer a spec-mandated limit.  And I think 30 days strikes a good balance between security benefits and safety, and is easy to remember and explain.

Trevor

Email secured by Check Point

_______________________________________________
websec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/websec

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 22 May 2013 22:02:12 +0100

<hat="individual">

Hi Trevor, hi all,

thanks for the thoughts.
Maybe a few comments and a question inline.

On 18/05/13 18:40, Trevor Perrin wrote:
>
> Hi Tobias, all,
>
> I think Tobias gives a fair summary of the arguments against a 30-day
> spec limit.  Let me summarize the opposing arguments:
>
>
> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> I hope pin assertions will *also* be processed by web crawlers to
> create pin lists which are made available to browsers (via preloaded
> lists, secure links, online lookups, etc.)
>
> frequency of re-crawling sites and re-downloading pin lists
> manageable.  Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin
expiry if we would have a hard limit in the RFC, but only if _all_
browsers will implement and use them. Which from my current
understanding is not on the horizon. At least I have seen no such
indications. Otherwise you get the varying implementations through
"creative approaches" you are worried about down below (and which I
don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose,
this would basically mean that all less frequent banking/paypal/...
users MUST (or a very strong SHOULD) use such a web crawler to make sure
that their pin has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not
be guaranteed nor expected to be rolled out consistently.

> Agreed that a 30-day limit is not, by itself, sufficient mitigation
> against "malicious bricking by an attacker after an attack".  I
> suspect pinning will need several additional mechanisms to prevent,
> limit, and recover from such attacks.  "Pin activation" is one
> mechanism I think is particularly helpful, for this case.
>
>  2) Preventing long-term lock-in.  E.g. you are pinned to CA keys
> which you lose trust in and suspect might be participating in MITM
> attacks; you are not bricked, but you are unable to change to a
> different CA and assert new CA pins until the old pins expire.
>  3) Pruning the amount of pin history you must keep your site
> consistent with (Do you remember what pins you or the previous domain
> owner asserted 6 month ago? 6 years ago? ever?  They might still be
> out there, waiting to trip you up).

Hm, in my view case #2 and #3 are about your own pinning time frames and
should be ok with recommendations, but would not require hard limits in
the draft. And in fact as we have multiple pins in the header we have a
migration path from A to B during that transition.

Reading your cases, it feels to me #1 the malicious domain name transfer
is the strongest case.
Is that in your opinion as well?
I am wondering how often that would happen? And whether we should not be
solving this through other means? (e.g. flushing the cache, reseting
this domain pin due to legal action or whatever?)

Overall, I still think it would be better not to assert a hard time
limit of 30 days in the doc.

(and if at all a time limit would be there, it should be at least 60
days, to cover users who revisit sites once per month which I imagine
many banking etc. users may do...).

I would be very interested to also read from others on the mailing-list
and the editors of the draft about their opinion on the web crawler, and
the use cases?

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 May 2013 21:21:45 +0000

Hi, Tobias

On May 23, 2013, at 12:02 AM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

<snip />

In that case, having pins last a month (instead of shorter) keeps the frequency of re-crawling sites and re-downloading pin lists manageable.  Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin expiry if we would have a hard limit in the RFC, but only if _all_ browsers will implement and use them. Which from my current understanding is not on the horizon. At least I have seen no such indications. Otherwise you get the varying implementations through "creative approaches" you are worried about down below (and which I don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose, this would basically mean that all less frequent banking/paypal/... users MUST (or a very strong SHOULD) use such a web crawler to make sure that their pin has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not be guaranteed nor expected to be rolled out consistently.

There is an alternative to the web crawler (although the crawler would be better). Your browser could refresh the pins in the background. If the pin is about to expire (say, in 7 days) and you have an Internet connection, the browser can silently open a connection to the server, see that the SSL handshake fits the pin, and refresh the entry in the local pin database. This won't scale very well if every site on the Internet has pins, but I don't really expect anyone to note more than several tens of pins (banking sites, some government, maybe things that accept credit cards). With less than 100 sites, you can make do with noting 3-4 pins per day, which shouldn't consume too much traffic.

I guess browsers would stop refreshing pins if you don't visit the site for a year.

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 22 May 2013 22:46:19 +0100

On 22/05/13 22:21, Yoav Nir wrote:
> Hi, Tobias
>
> On May 23, 2013, at 12:02 AM, Tobias Gondrom
>>> In that case, having pins last a month (instead of shorter) keeps
>>> the frequency of re-crawling sites and re-downloading pin lists
>> Would you agree that if we would do a 30-day hard limit as you
>> propose, this would basically mean that all less frequent
>> banking/paypal/... users MUST (or a very strong SHOULD) use such a
>> web crawler to make sure that their pin has not expired before they
>> come back?
>> This would be a big problem in my eyes, as IMHO this assumption can
>> not be guaranteed nor expected to be rolled out consistently.
>
> There is an alternative to the web crawler (although the crawler would
> be better). Your browser could refresh the pins in the background. If
> the pin is about to expire (say, in 7 days) and you have an Internet
> connection, the browser can silently open a connection to the server,
> see that the SSL handshake fits the pin, and refresh the entry in the
> local pin database. This won't scale very well if every site on the
> Internet has pins, but I don't really expect anyone to note more than
> several tens of pins (banking sites, some government, maybe things
> that accept credit cards). With less than 100 sites, you can make do
> with noting 3-4 pins per day, which shouldn't consume too much traffic.

Interesting idea.
And could this maybe also solve Trevor's concerns?

E.g. we could add to the spec some implementation advise, like "even if
the user does not visit the pinned sites, the browser SHOULD attempt in
the background to refresh recognized pins if they are about to expire or
before 30 days have passed...."

That way, pinning updates would come in earlier even though the visit is
maybe only monthly.
Could possibly solve Trevor's use cases #2 and #3?

Note: I would still not want the 30 day hard limit in the spec, because
I feel that this can give results that will be unexpected from a user
point of view...

Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 22 May 2013 15:29:32 -0700

Hi Yoav,

On Tue, May 21, 2013 at 3:26 PM, Yoav Nir <[email-masked]> wrote:

>  Hi Trevor
>
>  <no hats>
>
>  The suggestion that web spiders also note pins is interesting, but it's
> not mentioned in the draft at all.
>

I think this possibility should be mentioned.

The draft discusses "Preloaded Pin Lists", which are presumably conveyed to
the UA from some 3rd party (eg browser vendor).  It seems reasonable for
such lists to be created or kept fresh by scanning web sites.  I believe
Mozilla is taking this approach to HSTS [1].

Besides preloaded lists, there's other proposals that could discover pins
based on scans and then send fresh pins to clients (Convergence, S-Links,
Omnibroker, etc.)

So I think the draft should endorse the idea that pins might be discovered
by one party, then used by a second party.

If we agree this is a possible way to use server-asserted pins, then we
shouldn't assume that a 30-day pin is always worthless to a UA who can't
contact a site every 30 days.

> So I believe that we have to take the draft at face value, that it is user
> agents that are supposed to note pins. BTW: assuming that relatively few
> sites have pins, it is also possible for the browser itself to load pages
> in the background to refresh the list of pins.
>

Seems like a privacy risk to have the browser connecting back to pinned
sites on some interval.  Eg: you're at a coffee shop and your browser
decides to refresh pins for your embarrasing hobby sites.  Someone observes
these queries via sniffer...

If the global set of pins is small enough, the browser could periodically
fetch the entire thing (or the most important 10,000 pins, say).  I think
that's a practical, simple example of using 3rd-party infrastructure.

> Either way, we have to assume that the pin is noted by a user agent and is
> noted again only when the user clicks a link or types in the address again.
> I don't think we want to require anything else.
>
>  2) Preventing long-term lock-in.  E.g. you are pinned to CA keys which
> you lose trust in and suspect might be participating in MITM attacks; you
> are not bricked, but you are unable to change to a different CA and assert
> new CA pins until the old pins expire.
>  #2 and #3 make sense, but they only make sense as reasons to set max-age
> to a relatively short value. It may be good to incorporate this as advice
> to the administrator as to what to set max-age to. They are not a good
> reason, IMO, to set a hard limit in the protocol.
>

Not sure I agree.  #2 and #3 are consequences of long-lived bad pins
(lock-in to keys/CAs; and uncertainty over what pins might have been
asserted by previous sysadmins, domain owners, or attackers).

But these bad pins could arise from site mistakes, attacks, or previous
domain name owners, so asking sites to assert short-lived pins doesn't
guarantee they won't happen.

I'll try to break down the proposals for pin lifetimes:

 A) Sites assert short-lifetime pins
 B) UAs choose their own pin-lifetime limit
 C) Spec limit

(A) doesn't help with site mistakes, domain name transfers, or attacks
(disgruntled site administrator, hacker, or domain hijacker setting bad
pins, etc).

(B) doesn't give sites a guaranteed recovery period after which any bad
pins will disappear.  Let's say you acquire a new domain name, or you
suspect the previous admin was sloppy with pins, or a hacker might have set
bad pins.  If UAs can do whatever they want, then you can't be sure there
aren't bad pins hanging around somewhere, from *anything* that might have
happened *anytime* in the past.  Even if your domain seems to be working,
there could be bad "report-only" pins that are reporting on your users, or
that are locking you in to your current CA and which you might not discover
until you actually try to change CAs (months or years later)...

Anyways, a spec limit solves these problems - no matter what mistakes,
ownership changes, or attacks a domain name suffers, the site has a hard
guarantee that only the last 30 days of pin assertions matter.

Trevor

[1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 22 May 2013 15:45:50 -0700

>  I feel that this can give results that will be unexpected from a user

Sorry for not chiming in sooner, but I don't think we'd consider a polling
based solution as being viable for implementation.

We've certainly discussed these in-house and had discussions with other
browser vendors, and I don't think anyone is too enthused with the idea.

I can certainly understand and appreciate Trevor's concerns - and I
haven't really had a chance to sit down and give them the considered
response they deserve - but I did want to provide at least some feedback
before we got too far out there onto the 'background polling' bandwagon.

Cheers,
Ryan

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 22 May 2013 16:09:19 -0700

On Wed, May 22, 2013 at 2:02 PM, Tobias Gondrom
<[email-masked]>wrote:

> this would basically mean that all less frequent banking/paypal/... users
> MUST (or a very strong SHOULD) use such a web crawler to make sure that
> their pin has not expired before they come back?
>

Pins created by the UA itself won't protect initial connections, or provide
security when expired.  These are inherent limits of UA-derived pins.  So I
don't think a spec-limit makes these problems dramatically worse, or
requires new mandates for UAs.

You could, however, note the deficiences of UA-derived pins in the Security
Considerations, and say something something like:

"Clients are advised to make use of 3rd-party trust infrastructure so that
pins can be aggregated and shared.  This will require additional protocols
outside the scope of this document."

> This would be a big problem in my eyes, as IMHO this assumption can not be
> guaranteed nor expected to be rolled out consistently.
>
>
>
> against "malicious bricking by an attacker after an attack".  I suspect
> pinning will need several additional mechanisms to prevent, limit, and
> recover from such attacks.  "Pin activation" is one mechanism I think is
> particularly helpful, for this case.
>
> should be ok with recommendations, but would not require hard limits in the
> draft. And in fact as we have multiple pins in the header we have a

Being able to assert multiple pins in the header doesn't avoid lock-in
problems.  In a lock-in scenario there could be extant pins in clients to
the set of keys (X,Y,Z).  Thus you *cannot* safely stop using one of keys
(X,Y,Z) until those pins expire.

Advertising new pins doesn't fix the problem, cause you can't be guaranteed
of reaching all existing clients.

> Is that in your opinion as well?

Not sure.

Trevor

---

From: Chris Palmer <[email-masked]>
Date: Wed, 22 May 2013 17:14:50 -0700

Hi all,

Looks like these are the options:

1. No hard limits, but allow UAs to limit the pin time. Suggest a month

2. Set a hard limit of one month in the RFC. Longer pins are truncated.

3. No hard limits, but allow the UA to skip hard-fail if a pin hasn't been
observed for some time (like a month)

4. Adopt some gradual confidence-building scheme a-la-TACK.

5. No hard limits, leave limiting the pin time unspecified, make no
suggestion.

(4) is a key differentiator for TACK, and I want to let TACK be TACK and
HPKP be HPKP. I consider both to be experimental features, and having two
very different proposals maximizes our experimentation coverage.

Any of (1, 2, 3, 5) is more or less fine by me; I'll go along with the
consensus. I see them as being on a spectrum of "fixity" or "definedness":

least fixed . . . most fixed
5        3        1        2

Perhaps in this time of experimentation, less fixed is better. Maybe we can
learn more about how well/not well pinning works, and then publish a new
version of the specification in the future.

I posit that browsers will have strong incentives to fail open after some
reasonable max-max-age, even if the spec does not mandate it. (For example,
Chrome stops enforcing pinning completely if it recognizes that its own
build date is more than 10 weeks in the past: a browser that old is
definitely an indicator of some kind of problem, and we want users to be
able to recover.) So, not mandating a limit is not as dangerous as it may
seem, as a practical matter.

However, Trevor compellingly argues: """Anyways, I think making things safe
and simple for site operators is more important than browser creativity, or
trying to maximize pinning's security benefits.  That's why I still prefer
a spec-mandated limit. And I think 30 days strikes a good balance between
security benefits and safety, and is easy to remember and explain."""

I am less compelled by the argument that rarely-visited sites will get no
protection from pinning if the max-max-age is as low as 30 days, if the
fail-open behavior is to provide the user a warning/notice/choice:

    Hey, you haven't visited yourbank.com recently enough for us to be
highly
    confident that it's the real yourbank.com. Everything else checks out,
so
    we still have good confidence.

    [ I'm OK with good confidence, proceed anyway ]        [ Oops, go back ]

So, my vote is for (3).

---

From: Daniel Veditz <[email-masked]>
Date: Wed, 22 May 2013 19:43:16 -0700

On 5/22/2013 3:29 PM, Trevor Perrin wrote:
> The draft discusses "Preloaded Pin Lists", which are presumably conveyed
> to the UA from some 3rd party (eg browser vendor).  It seems reasonable
> for such lists to be created or kept fresh by scanning web sites.  I
> believe Mozilla is taking this approach to HSTS [1].

Note that Mozilla currently requires sites to specify an HSTS pinning 
time of at least 18 WEEKS to be included in the pre-load list. There was 
concern that sites with shorter pins could have stopped using HSTS by 
time that version of the browser shipped. I personally think that's a 
little strict, but even if we relaxed the requirement to the length of a 
Beta cycle that's still a longer period of time (6 weeks) than the 
maximum 30 days you're suggesting.

This has no direct bearing of whether 30 days is a reasonable max 
pinning length, but I doubt Mozilla would ship a pre-loaded list if the 
lifetime was so short that pins would have expired by time the user gets it.

-Dan Veditz

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 23 May 2013 08:17:57 -0700

On Wed, May 22, 2013 at 7:43 PM, Daniel Veditz <[email-masked]> wrote:

> Note that Mozilla currently requires sites to specify an HSTS pinning time
> of at least 18 WEEKS to be included in the pre-load list. There was concern
> that sites with shorter pins could have stopped using HSTS by time that
> version of the browser shipped. I personally think that's a little strict,
> but even if we relaxed the requirement to the length of a Beta cycle that's
> still a longer period of time (6 weeks) than the maximum 30 days you're
> suggesting.
>

Hi Daniel,

That seems like a downside of compiling preloads into browser binaries, as
done by Chrome and Firefox.

But it looks like Google and Mozilla have both considered having the
browser query a service to update a local list.  That seems like a better
approach, since it would eliminate this problem of shipping a build with
pin information that is several weeks stale, and can only be updated with a
new browser binary.

https://code.google.com/p/chromium/issues/detail?id=175207
"As both the pinning list grows, and our desire to have a consistent
pinning list across all versions of Chromium, we should look to move the
static pin database into a module that may be updated independently of the
main Chromium binary."

https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List
"There are two ways to accomplish this:
1. Hard-code the list in each shipping version of Firefox
2. Stand up a service (like blocklist ping) that serves the list upon
request."

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 28 May 2013 12:51:56 +0100

Hi Chris,

<hat="individual">

It seems like the majority of the WG would not share my concerns. So I
will shut up soon. ;-)

Maybe two remarks:
1. user choice is a bad idea when it comes to security.
Just remember the many SSL cert "click to proceed anyway pop-up
windows/issues..."
In most cases the user is not qualified to fully understand the
consequences of his choice. And also if he is faced with the choice "no
access" or "access", he/she will probably go for "access anyway". We
have trained them that way the last few years.
So I rather want to avoid a user choice as much as possible.

2. as you seem to advocate a hard limit of 30 days. Could you think of
browsers refreshing their PINs before expiry automatically? (i.e.
without the user actually visiting the site?)
And question to all: would this open Pandora's box in terms of privacy
etc. as we would leak the list of pinned sites to servers in the middle?

Best regards, Tobias

On 23/05/13 01:14, Chris Palmer wrote:
> 3. No hard limits, but allow the UA to skip hard-fail if a pin hasn't
> (4) is a key differentiator for TACK, and I want to let TACK be TACK
> and HPKP be HPKP. I consider both to be experimental features, and
> having two very different proposals maximizes our experimentation
> coverage.
>
> Perhaps in this time of experimentation, less fixed is better. Maybe
> we can learn more about how well/not well pinning works, and then
> publish a new version of the specification in the future.
>
> I posit that browsers will have strong incentives to fail open after
> some reasonable max-max-age, even if the spec does not mandate it.
> (For example, Chrome stops enforcing pinning completely if it
> recognizes that its own build date is more than 10 weeks in the past:
> a browser that old is definitely an indicator of some kind of problem,
> and we want users to be able to recover.) So, not mandating a limit is
> not as dangerous as it may seem, as a practical matter.
>
> However, Trevor compellingly argues: """Anyways, I think making things
> safe and simple for site operators is more important than browser
> creativity, or trying to maximize pinning's security benefits.  That's
> why I still prefer a spec-mandated limit. And I think 30 days strikes
> a good balance between security benefits and safety, and is easy to
> remember and explain."""
>
> I am less compelled by the argument that rarely-visited sites will get
> no protection from pinning if the max-max-age is as low as 30 days, if
> the fail-open behavior is to provide the user a warning/notice/choice:
>
>     Hey, you haven't visited yourbank.com <http://yourbank.com>
> recently enough for us to be highly
>     confident that it's the real yourbank.com <http://yourbank.com>.
> Everything else checks out, so

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 28 May 2013 12:53:46 +0100

Hi Dan,
<hat="individual">
thank you for the info. And a good point.
Tobias

On 23/05/13 03:43, Daniel Veditz wrote:
> time of at least 18 WEEKS to be included in the pre-load list. There
> was concern that sites with shorter pins could have stopped using HSTS
> by time that version of the browser shipped. I personally think that's
> a little strict, but even if we relaxed the requirement to the length
> of a Beta cycle that's still a longer period of time (6 weeks) than
> the maximum 30 days you're suggesting.
>
> pinning length, but I doubt Mozilla would ship a pre-loaded list if
> the lifetime was so short that pins would have expired by time the
> user gets it.
>
> -Dan Veditz
>
>
>
>

---

From: Chris Palmer <[email-masked]>
Date: Tue, 28 May 2013 17:23:48 -0700

> It seems like the majority of the WG would not share my concerns. So I

Thanks for raising your concerns, and for sticking the conversation
and with pinning in general!

> consequences of his choice.

Yes. But, in this case, the choice is between status-quo HTTPS and
extra-happy pinned HTTPS. That's a very different proposition than
clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing
closed would probably be a deal-breaker for deployment, at least at
this time. Finally, for sites that people use regularly — Facebook,
Gmail, Twitter — users will still get good protection. Arguably, these
are the sites that are mature and most likely to be able to deploy
pinning; it's the banks and other occasionally-visited sites that
should probably stick to Report-Only mode anyway, because they are
less mature *as web technology companies*. Thus I would argue that, at
least for now, the sites that would most likely fail open due to limit
son the max-max-age are sites that should fail open anyway, for other
reasons.

However, that's a bit of a tangent. As it is, many sites that really
need pinning protection can get it under this I-D, and others can gain
nice information from Report-Only mode, and others do no worse than
the status quo.

> 2. as you seem to advocate a hard limit of 30 days.

Not exactly; I find Trevor's call for simple clarity compelling, but I
also like a browser-determined limit past which we fail open (for the
reasons described above). I could happily go either way, which doesn't
really help, I realize. :) Ryan and I can just make a call one way or
the other and write it up, is that OK?

> Could you think of

Right, exactly. I don't want to have browsers unilaterally leaking
information by proactively pre-scanning particular sites. However, an
oft-updated master list, like Chrome's CRLSets but for pins culled by
crawling sites and looking for pin updates, might be workable. But I'd
consider that a nice-to-have that is out of the I-D's immediate scope.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 May 2013 05:16:56 +0000

Hi Chris

(again, no hats)

On May 29, 2013, at 3:23 AM, Chris Palmer <[email-masked]> wrote:

> pinning;

People having multiple devices kind of screws this up. People may use the same site every day, but they might not use the same site from the same device every day. So if someone uses mostly a phone to access facebook, they may go a whole month without accessing it from their desktop or laptop. Limiting pins to 30 days means your less-used devices, which may be on a totally different network than your phone, are not protected.

> it's the banks and other occasionally-visited sites that

Disagree on that. Banks and other financial institutions are not web technology companies, but they deal with real money and they have real money with which to buy such expertise. It's no coincidence that banks were very early adopters of anti-XSS and anti-CSRF measures, and it's no coincidence that one of this group's biggest contributors works for Paypal, which is no less a financial institution than any bank or credit card companies. If we can't help protect the transactions that involve money, what's the point?

> the other and write it up, is that OK?

By "fail open", do you mean fail with a warning to the user, or just silently ignore the pin?  If it's the latter, than letting each implementation choose a max-max-age does not address Trevor's concerns. If some site sent a pin with max-age of 10 years, they can fix the pin that they send, but they have to assume that for the next 10 years some browsers out there have recorded the way-too-long pin. Maybe this means that they can't switch root CAs. If you set max-max-age in the RFC to 30 days, they can know that all those browsers will have lost the pin after a month. If you let every UA choose their own max-max-age, they have to assume the maximum, and hope that they even know the maximum. They might think that taking the maximum among Chrome, Firefox, IE, Safari and Opera gets them there. They might not have ever heard of a browser called OmniWeb for Mac (just using an obscure one as an example). But if OmniWeb sets no limits on pins and they change CAs after 1 year, they are going to get a whole bunch of support calls from people using a browser they've never heard of.

So I think we should either set no limits, or set hard limits.

> consider that a nice-to-have that is out of the I-D's immediate scope.

I agree that we can't mandate that each UA has access to the results of some web crawler looking for pins.

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 29 May 2013 16:04:26 +0100

Hi Chris,

(also no hats)

thanks for the clarification.
If either "no-limit" and "hard-limit" would both be ok for you (and
others), then I would be strongly in favor of "no-limit".
(note: I recognise that the side effect of "no-limit" is that domain
squatters can brick a site for a longer time after the domain had been
handed over. But actually considering that we plan to do some
pre-caching deployment in browsers anyway, the browsers might also be
the solution for this problem. Like doing a "clear pin cache for domain
xyz" in case of really malicious pin bricking.)

Best regards, Tobias

---

From: Chris Palmer <[email-masked]>
Date: Wed, 29 May 2013 17:29:35 -0700

> Disagree on that. Banks and other financial institutions are not web technology companies, but they deal with real money and they have real money with which to buy such expertise. It's no coinciden…

Money is not the only important thing to protect. If HPKP "merely"
protected email or personal messages or social networks, that would
still be pretty awesome — because people often use those systems for
things at least as important as money. (E.g. political speech.) Yes,
of course I want to also protect people's interactions with their
financial institutions.

> By "fail open", do you mean fail with a warning to the user, or just silently ignore the pin?

Fail with a warning to the user, as described earlier.

> So I think we should either set no limits, or set hard limits.

I see in a subsequent email, Tobias says:

"""If either "no-limit" and "hard-limit" would both be ok for you (and
others), then I would be strongly in favor of "no-limit"."""

I'll go for no-mandated-limit with suggested-limit.

Other votes?