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

From: Yoav Nir <[email-masked]>
Date: Sun, 2 Jun 2013 06:41:57 +0000

Hi

Just trying to get us close to consensus. Still no hats. There are two arguments for limiting max-age:

1. With unlimited max-age, it's possible for the legitimate site owner to by mistake damage their sites. You could pin the CA certificate, and lock yourself in to that CA for all eternity. You could pin a current and future EE public keys, and then when the current public key expires, you might not use the future one because you mistyped it (or your CA no longer accepts 1024-bit keys). For whatever reason, a bad choice you make while trying out HPKP either bricks your site or constrains your behavior for a while.

2. With unlimited max-age, a current owner of a domain name can set a pin that a future owner cannot honor. So if Mr. diaper consultant[1] ever decides to retire, he could set a long-lived pin such that I would not be able to use the domain even if I buy it. A variation on this is the case where an attacker like ComodoHacker manages to MitM a popular site, and he sets a long-lived pin that prevents users from accessing the site not through the MitM. This means that browser support for HPKP could serve to amplify attacks that are plenty bad enough as they are.

Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty big gun with which users can shoot themselves in the foot. A website that's important for its owner (whether it's social networking, political action, or business) cannot afford to be inaccessible for any length of time. A month is no less a disaster than a year. As for constraining your behavior, this merits deployment advice, not limiting the usefulness of the protocol for other sites.

#2 is more worrying. I think the previous owner issue would be served even with a 1 year hard limit, and I don't think anyone here is arguing that a 1-year limit is too short. But the attack amplification is a real thing, and it works against sites that haven't even implemented HPKP. Sites that deploy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). But having HPKP in the browser (but not in the website) allows his friends to lock out browsers by inserting a pin. So if browsers implement this, it amplifies attacks against the general population of SSL-protected web sites. I'm not sure whether in the grand scheme of things this makes the Internet better or worse.

Note, though, that this issue exists even if max-age is limited. Bricking the site for a month (for some users in Iran) is a bad enough outcome, only slightly mitigated by it being only for a month.

I started out writing this message thinking it was going to have a proposal that we could all reach consensus about. I'm not sure I got there. I guess if this was a vote, I would vote for a year-long max-max-age, but I'm not really as sure about this as I was when I started writing this message.

Yoav

[1] http://www.yoavnir.com

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 2 Jun 2013 23:29:21 -0700

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins.  We should also
think more about the benefits.

I'll argue that pin lifetimes past a certain point don't get you much.
 Browser-based "key continuity" will hopefully be supplemented by systems
that scan pin assertions regularly from different points on the Internet
(like Perspectives, Convergence, Vantages, etc.).  Such systems would
derive pins more reliably than individual browsers, and could use several
methods to distribute these pins.  Since scanning of sites can be done
frequently, and distribution would also be fast, long-lived pins aren't
needed for this.

The hard part of this isn't scanning, it's pin distribution.  Here's three
ways that could be done:

Links:  Pins could be embedded in hyperlinks served over HTTPS.  Since much
browsing consists of following links from the web's major "introducers"
(search engines, social networks, etc.), having these sites embed pins
would protect a lot of traffic.  See the recent "S-links" paper [1].

Lists:  Modern browsers download lists of security info on a regular basis,
including lists of malware and phishing sites [2], commonly-downloaded
files [3], and revoked certs [4].  You could imagine pin lists being
downloaded, so that every browser has a current list of pins for, say,
10,000 major sites.

Lookups:  Browsers are reluctant to do per-connection blocking lookups (see
OCSP, Convergence, and DNSSEC).  But there might be more efficient and
less-problematic ways to combine pin and DNS lookups (e.g. connections to
DNS resolvers via VPNs, or some simpler form of response authentication).
 Also, non-blocking pin lookups could be used after-the-fact to detect
attacks (if a MITM blocks the lookup for an extended period, the browser
would start complaining).

Anyways, 30-day pins seem adequate for any of these.  Assuming sites can be
rescanned weekly, pins received through links, lists, or lookups are likely
to have 20+ days of validity left in them, which is plenty of time for the
browser to follow a link, or use a list without its entries expiring.

This is a complicated issue, and I don't expect this email to resolve it.
 But I at least hope this lessens any perception that short-lived pins
would offer weak security.

Trevor

[1] http://research.google.com/pubs/archive/41138.pdf
[2] https://developers.google.com/safe-browsing/
[3]
http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9
[4] http://www.imperialviolet.org/2012/02/05/crlsets.html

On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <[email-masked]> wrote:

> 1. With unlimited max-age, it's possible for the legitimate site owner to
> by mistake damage their sites. You could pin the CA certificate, and lock
> yourself in to that CA for all eternity. You could pin a current and future
> EE public keys, and then when the current public key expires, you might not
> use the future one because you mistyped it (or your CA no longer accepts
> 1024-bit keys). For whatever reason, a bad choice you make while trying out
> HPKP either bricks your site or constrains your behavior for a while.
>
> 2. With unlimited max-age, a current owner of a domain name can set a pin
> that a future owner cannot honor. So if Mr. diaper consultant[1] ever
> decides to retire, he could set a long-lived pin such that I would not be
> able to use the domain even if I buy it. A variation on this is the case
> where an attacker like ComodoHacker manages to MitM a popular site, and he
> sets a long-lived pin that prevents users from accessing the site not
> through the MitM. This means that browser support for HPKP could serve to
> amplify attacks that are plenty bad enough as they are.
>
> Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty
> big gun with which users can shoot themselves in the foot. A website that's
> important for its owner (whether it's social networking, political action,
> or business) cannot afford to be inaccessible for any length of time. A
> month is no less a disaster than a year. As for constraining your behavior,
> this merits deployment advice, not limiting the usefulness of the protocol
> for other sites.
>
> #2 is more worrying. I think the previous owner issue would be served even
> with a 1 year hard limit, and I don't think anyone here is arguing that a
> 1-year limit is too short. But the attack amplification is a real thing,
> and it works against sites that haven't even implemented HPKP. Sites that
> deploy HPKP are protected from a MitM such as ComodoHacker (or his
> "friends"). But having HPKP in the browser (but not in the website) allows
> his friends to lock out browsers by inserting a pin. So if browsers
> implement this, it amplifies attacks against the general population of
> SSL-protected web sites. I'm not sure whether in the grand scheme of things
> this makes the Internet better or worse.
>
> Note, though, that this issue exists even if max-age is limited. Bricking
> the site for a month (for some users in Iran) is a bad enough outcome, only
> slightly mitigated by it being only for a month.
>
> I started out writing this message thinking it was going to have a
> proposal that we could all reach consensus about. I'm not sure I got there.
> I guess if this was a vote, I would vote for a year-long max-max-age, but
> I'm not really as sure about this as I was when I started writing this
> message.
>
> Yoav
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 04 Jun 2013 11:04:19 +0100

Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin
lists.

But your idea might in fact be a solution to enable the unlimited pin
times.
Instead of constantly distributing the list of pins, we could actually
have browsers use whitelists of pins that have been "revoked" and where
the browser is allowed to refresh. That could e.g. happen with a browser
update.
That way we can have a unlimited time pin (and pre-caching of pins) and
solve the scenario of malicious domain blocking by previous owners. And
hopefully that scenario will hardly happen at all (especially if there
is a provision for solving it and the attempt is futile, the motivation
for an attacker trying it might be close to zero).

Best regards, Tobias

On 03/06/13 07:29, Trevor Perrin wrote:
>  Browser-based "key continuity" will hopefully be supplemented by
> systems that scan pin assertions regularly from different points on
> the Internet (like Perspectives, Convergence, Vantages, etc.).  Such
> systems would derive pins more reliably than individual browsers, and
> could use several methods to distribute these pins.  Since scanning of
> sites can be done frequently, and distribution would also be fast,
> long-lived pins aren't needed for this.
>
> The hard part of this isn't scanning, it's pin distribution.  Here's
> three ways that could be done:
>
> Links:  Pins could be embedded in hyperlinks served over HTTPS.  Since
> much browsing consists of following links from the web's major
> "introducers" (search engines, social networks, etc.), having these
> sites embed pins would protect a lot of traffic.  See the recent
> "S-links" paper [1].
>
> Lists:  Modern browsers download lists of security info on a regular
> basis, including lists of malware and phishing sites [2],
> commonly-downloaded files [3], and revoked certs [4].  You could
> imagine pin lists being downloaded, so that every browser has a
> current list of pins for, say, 10,000 major sites.
>
> Lookups:  Browsers are reluctant to do per-connection blocking lookups
> (see OCSP, Convergence, and DNSSEC).  But there might be more
> efficient and less-problematic ways to combine pin and DNS lookups
> (e.g. connections to DNS resolvers via VPNs, or some simpler form of
> response authentication).  Also, non-blocking pin lookups could be
> used after-the-fact to detect attacks (if a MITM blocks the lookup for
> an extended period, the browser would start complaining).
>
>
> Anyways, 30-day pins seem adequate for any of these.  Assuming sites
> can be rescanned weekly, pins received through links, lists, or
> lookups are likely to have 20+ days of validity left in them, which is
> plenty of time for the browser to follow a link, or use a list without
> its entries expiring.
>
> This is a complicated issue, and I don't expect this email to resolve
> it.  But I at least hope this lessens any perception that short-lived
> pins would offer weak security.
>
>
> Trevor
>
> On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi
>
>     1. With unlimited max-age, it's possible for the legitimate site
>     owner to by mistake damage their sites. You could pin the CA
>     certificate, and lock yourself in to that CA for all eternity. You
>     could pin a current and future EE public keys, and then when the
>     current public key expires, you might not use the future one
>     because you mistyped it (or your CA no longer accepts 1024-bit
>     keys). For whatever reason, a bad choice you make while trying out
>     2. With unlimited max-age, a current owner of a domain name can
>     set a pin that a future owner cannot honor. So if Mr. diaper
>     consultant[1] ever decides to retire, he could set a long-lived
>     pin such that I would not be able to use the domain even if I buy
>     it. A variation on this is the case where an attacker like
>     ComodoHacker manages to MitM a popular site, and he sets a
>     long-lived pin that prevents users from accessing the site not
>     through the MitM. This means that browser support for HPKP could
>     serve to amplify attacks that are plenty bad enough as they are.
>
>     Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a
>     pretty big gun with which users can shoot themselves in the foot.
>     A website that's important for its owner (whether it's social
>     networking, political action, or business) cannot afford to be
>     inaccessible for any length of time. A month is no less a disaster
>     than a year. As for constraining your behavior, this merits
>     deployment advice, not limiting the usefulness of the protocol for
>     other sites.
>
>     #2 is more worrying. I think the previous owner issue would be
>     served even with a 1 year hard limit, and I don't think anyone
>     here is arguing that a 1-year limit is too short. But the attack
>     amplification is a real thing, and it works against sites that
>     haven't even implemented HPKP. Sites that deploy HPKP are
>     protected from a MitM such as ComodoHacker (or his "friends"). But
>     having HPKP in the browser (but not in the website) allows his
>     friends to lock out browsers by inserting a pin. So if browsers
>     implement this, it amplifies attacks against the general
>     population of SSL-protected web sites. I'm not sure whether in the
>     grand scheme of things this makes the Internet better or worse.
>
>     Note, though, that this issue exists even if max-age is limited.
>     Bricking the site for a month (for some users in Iran) is a bad
>     enough outcome, only slightly mitigated by it being only for a month.
>
>     proposal that we could all reach consensus about. I'm not sure I
>     got there. I guess if this was a vote, I would vote for a
>     year-long max-max-age, but I'm not really as sure about this as I
>     was when I started writing this message.
>
>     Yoav
>
>     [email-masked] <mailto:[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Jun 2013 11:07:38 +0000

But doesn't this introduce a lot of infrastructure?

If we want to find out a hash of the public key for an HTTPS server using heavy infrastructure, we might as well use DANE, no?

Yoav

On Jun 4, 2013, at 1:04 PM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin lists.

But your idea might in fact be a solution to enable the unlimited pin times.
Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That could e.g. happen with a browser update.
That way we can have a unlimited time pin (and pre-caching of pins) and solve the scenario of malicious domain blocking by previous owners. And hopefully that scenario will hardly happen at all (especially if there is a provision for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero).

Best regards, Tobias

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins.  We should also think more about the benefits.

I'll argue that pin lifetimes past a certain point don't get you much.  Browser-based "key continuity" will hopefully be supplemented by systems that scan pin assertions regularly from different points on the Internet (like Perspectives, Convergence, Vantages, etc.).  Such systems would derive pins more reliably than individual browsers, and could use several methods to distribute these pins.  Since scanning of sites can be done frequently, and distribution would also be fast, long-lived pins aren't needed for this.

The hard part of this isn't scanning, it's pin distribution.  Here's three ways that could be done:

Links:  Pins could be embedded in hyperlinks served over HTTPS.  Since much browsing consists of following links from the web's major "introducers" (search engines, social networks, etc.), having these sites embed pins would protect a lot of traffic.  See the recent "S-links" paper [1].

Lists:  Modern browsers download lists of security info on a regular basis, including lists of malware and phishing sites [2], commonly-downloaded files [3], and revoked certs [4].  You could imagine pin lists being downloaded, so that every browser has a current list of pins for, say, 10,000 major sites.

Lookups:  Browsers are reluctant to do per-connection blocking lookups (see OCSP, Convergence, and DNSSEC).  But there might be more efficient and less-problematic ways to combine pin and DNS lookups (e.g. connections to DNS resolvers via VPNs, or some simpler form of response authentication).  Also, non-blocking pin lookups could be used after-the-fact to detect attacks (if a MITM blocks the lookup for an extended period, the browser would start complaining).

Anyways, 30-day pins seem adequate for any of these.  Assuming sites can be rescanned weekly, pins received through links, lists, or lookups are likely to have 20+ days of validity left in them, which is plenty of time for the browser to follow a link, or use a list without its entries expiring.

This is a complicated issue, and I don't expect this email to resolve it.  But I at least hope this lessens any perception that short-lived pins would offer weak security.

Trevor

[1] http://research.google.com/pubs/archive/41138.pdf
[2] https://developers.google.com/safe-browsing/
[3] http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9
[4] http://www.imperialviolet.org/2012/02/05/crlsets.html

On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Yoav

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

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

Email secured by Check Point

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 04 Jun 2013 12:21:25 +0100

Well. I am not strongly voting for it.

The point is, to have a hard limit of 30 days under the assumption of
the existence of such infrastructure would be worse, because then we
would need to rely on such infrastructure in all normal operation cases.
While with my approach we would need the infrastructure only in the
exception (of a malicious attacker abusing key pinning to block a
domain), which may or may not happen at all.

Best, Tobias

On 04/06/13 12:07, Yoav Nir wrote:
> If we want to find out a hash of the public key for an HTTPS server
> using heavy infrastructure, we might as well use DANE, no?
>
> Yoav
>
> On Jun 4, 2013, at 1:04 PM, Tobias Gondrom <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi Trevor, hi all,
>>
>> (again no hats)
>>
>> Instead of constantly distributing the list of pins, we could
>> actually have browsers use whitelists of pins that have been
>> "revoked" and where the browser is allowed to refresh. That could
>> e.g. happen with a browser update.
>> That way we can have a unlimited time pin (and pre-caching of pins)
>> and solve the scenario of malicious domain blocking by previous
>> owners. And hopefully that scenario will hardly happen at all
>> (especially if there is a provision for solving it and the attempt is
>> futile, the motivation for an attacker trying it might be close to zero).
>>
>> Best regards, Tobias
>>
>>
>>
>>
>>> I'll argue that pin lifetimes past a certain point don't get you
>>> much.  Browser-based "key continuity" will hopefully be supplemented
>>> by systems that scan pin assertions regularly from different points
>>> on the Internet (like Perspectives, Convergence, Vantages, etc.).
>>>  Such systems would derive pins more reliably than individual
>>> browsers, and could use several methods to distribute these pins.
>>>  Since scanning of sites can be done frequently, and distribution
>>> would also be fast, long-lived pins aren't needed for this.
>>>
>>> Links:  Pins could be embedded in hyperlinks served over HTTPS.
>>>  Since much browsing consists of following links from the web's
>>> major "introducers" (search engines, social networks, etc.), having
>>> these sites embed pins would protect a lot of traffic.  See the
>>> recent "S-links" paper [1].
>>>
>>> Lookups:  Browsers are reluctant to do per-connection blocking
>>> lookups (see OCSP, Convergence, and DNSSEC).  But there might be
>>> more efficient and less-problematic ways to combine pin and DNS
>>> lookups (e.g. connections to DNS resolvers via VPNs, or some simpler
>>> form of response authentication).  Also, non-blocking pin lookups
>>> could be used after-the-fact to detect attacks (if a MITM blocks the
>>> lookup for an extended period, the browser would start complaining).
>>>
>>>
>>> lookups are likely to have 20+ days of validity left in them, which
>>> is plenty of time for the browser to follow a link, or use a list
>>> without its entries expiring.
>>>
>>> This is a complicated issue, and I don't expect this email to
>>> resolve it.  But I at least hope this lessens any perception that
>>> short-lived pins would offer weak security.
>>>
>>>
>>> Trevor
>>>
>>> <http://research.google.com/pubs/archive/41138.pdf>
>>> <https://developers.google.com/safe-browsing/>
>>> [3]
>>>     certificate, and lock yourself in to that CA for all eternity.
>>>     You could pin a current and future EE public keys, and then when
>>>     the current public key expires, you might not use the future one
>>>     keys). For whatever reason, a bad choice you make while trying
>>>     out HPKP either bricks your site or constrains your behavior for
>>>     a while.
>>>
>>>     pin such that I would not be able to use the domain even if I
>>>     buy it. A variation on this is the case where an attacker like
>>>     Regarding #1 I'm not convinced. HPKP (much like HSTS) is already
>>>     a pretty big gun with which users can shoot themselves in the
>>>     foot. A website that's important for its owner (whether it's
>>>     social networking, political action, or business) cannot afford
>>>     to be inaccessible for any length of time. A month is no less a
>>>     disaster than a year. As for constraining your behavior, this
>>>     merits deployment advice, not limiting the usefulness of the
>>>     protocol for other sites.
>>>
>>>     protected from a MitM such as ComodoHacker (or his "friends").
>>>     But having HPKP in the browser (but not in the website) allows
>>>     his friends to lock out browsers by inserting a pin. So if
>>>     browsers implement this, it amplifies attacks against the
>>>     general population of SSL-protected web sites. I'm not sure
>>>     whether in the grand scheme of things this makes the Internet
>>>     better or worse.
>>>
>>>     I started out writing this message thinking it was going to have
>>>     a proposal that we could all reach consensus about. I'm not sure
>>>     I got there. I guess if this was a vote, I would vote for a
>>>     year-long max-max-age, but I'm not really as sure about this as
>>>     I was when I started writing this message.
>>>
>>>     Yoav
>>>
>>>     [1] http://www.yoavnir.com <http://www.yoavnir.com/>

---

From: "Sheehe, Charles J. (GRC-DPC0)" <[email-masked]>
Date: Tue, 4 Jun 2013 08:03:15 -0500

Why can't the Max-Max-AGE  equal a formula  Max age=  (average usage)*2+1day

This should accommodate both and not the best for either.

Chuck
From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, June 04, 2013 7:08 AM
To: Tobias Gondrom
Cc: <[email-masked]>
Subject: Re: [websec] Consensus call: Issue #57 (max-max-age)

Yoav

Hi Trevor, hi all,

(again no hats)

Best regards, Tobias

Hi Yoav, all,

Trevor

Yoav

websec mailing list

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 4 Jun 2013 08:21:14 -0700

On Tue, Jun 4, 2013 at 3:04 AM, Tobias Gondrom
<[email-masked]>wrote:

> have browsers use whitelists of pins that have been "revoked" and where the
> browser is allowed to refresh. That could e.g. happen with a browser update.
>

Hi Tobias,

I agree there may need to be a mechanism for browser vendors (or other
third parties) to push out "pin revocation lists" that delete bad pins.

But if a bad pin occurs, there may be some latency before this list could
be updated.  And if a lot of bad pins occur, the list might not be large
enough to contain them all.

So I still think we want strong safeguards (such as max-age limits) to
reduce the incidence of bad pins as much as possible.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 4 Jun 2013 08:24:36 -0700

> using heavy infrastructure, we might as well use DANE, no?

If TLSA records have typical DNS TTLs (a few hours or days), then they will
probably be too short-lived to be effectively stored in lists and
downloaded to browsers, etc.

If they are longer-lived, then all the issues we're discussing here will
still arise (a DNS hijacker or disgruntled sysadmin setting a long-lived
DANE pin, etc.).

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 4 Jun 2013 09:31:45 -0700

On Tue, Jun 4, 2013 at 6:03 AM, Sheehe, Charles J. (GRC-DPC0) <
[email-masked]> wrote:

> Why can’t the Max-Max-AGE  equal a formula  Max age=  (average
> usage)*2+1day
>

Hi Charles,

In the case of frequently visited sites, that would shrink pin lifetimes to
the point that even a brief interruption of browsing habits (vacation,
etc.) would deactivate the pins.

Also, that wouldn't guarantee an upper-bound on pin lifetimes.  While
opinions differ on this, I think a guaranteed upper-bound is desirable, to
provide sites clarity on how long ill-effects from pinning might last.

Trevor

---

From: "Sheehe, Charles J. (GRC-DPC0)" <[email-masked]>
Date: Tue, 4 Jun 2013 14:52:53 -0500

Thanks Trevor.

Ok so if we set the Max Age to 1 day or 10 days or 30 or 90 so what are the realistic impacts? Increased Infrastructure how much?  I have not seen the tradeoffs cost(risks or added infrastructure) vs. benefits. I have been reading the argument pro's and con's and the issue does not seem to be an engineering one it is a business/risk management issue.  Upset customers, security, operations costs etc..  Not knowing the business cases and true costs I would go with 28 days if a hard limit must be set.  That seems long to me yet within most business systems reporting cycles etc..

Just my thoughts
Chuck

From: Trevor Perrin [mailto:[email-masked]]
Sent: Tuesday, June 04, 2013 12:32 PM
To: Sheehe, Charles J. (GRC-DPC0)
Cc: <[email-masked]>
Subject: Re: [websec] Consensus call: Issue #57 (max-max-age)

On Tue, Jun 4, 2013 at 6:03 AM, Sheehe, Charles J. (GRC-DPC0) <[email-masked]<mailto:[email-masked]>> wrote:
Why can't the Max-Max-AGE  equal a formula  Max age=  (average usage)*2+1day

Hi Charles,

In the case of frequently visited sites, that would shrink pin lifetimes to the point that even a brief interruption of browsing habits (vacation, etc.) would deactivate the pins.

Also, that wouldn't guarantee an upper-bound on pin lifetimes.  While opinions differ on this, I think a guaranteed upper-bound is desirable, to provide sites clarity on how long ill-effects from pinning might last.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 5 Jun 2013 09:42:44 -0700

On Tue, Jun 4, 2013 at 12:52 PM, Sheehe, Charles J. (GRC-DPC0) <
[email-masked]> wrote:

> Thanks Trevor.  ****
>
> ** **
>
> Ok so if we set the Max Age to 1 day or 10 days or 30 or 90 so what are
> the realistic impacts? Increased Infrastructure how much?  I have not seen
> the tradeoffs cost(risks or added infrastructure) vs. benefits.
>

So, assuming (for sake of discussion) that we wanted *some* spec-defined
max-max-age, what are the tradeoffs in choosing it?

Good question, I think you'd want to start by being clear what use cases
are in scope.  I suggested expanding the scope to include pin-distribution
methods like "downloaded lists", "secure links", and "online lookups".  It
would be fair for the working group to reject that scope expansion, or
discuss further.

Then we could look at how the effectiveness of pins varies over time for
different use cases.  I'd argue that for the expanded use cases, you get
diminishing returns on effectiveness after a few weeks, though for the
"browser key continuity" use case, it's a different story, so we'd have to
decide how to weigh the use cases.

Finally, you'd have to assess how the "dangers" of pinning increase with
lifetime, and then subtract the dangers from the benefits to get some
"pinning-lifetime-utility" curve.  In my mind, this curve is a bell-like
thing with a lot of mass between a few weeks and a few months, with 30 days
being a good round number in the middle.

At least that's how TACK got there, that's as methodical as we got...

Trevor