Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 7 Nov 2014 14:28:42 -0500

Thank you for comment! I agree with you that setting a HSTS policy that never expires might be somewhat risky, and I totally agree with your answers to this concern. And I want to add more thoughts about it.

The current RFC 6797 doesn't specify or even recommend an upper limit for the max-age. So it's possible that sites specify a very long time span. However, all the concerns of infinite HSTS also apply to extremely-long HSTS.

For instance, if Twitter wants to gracefully switch to HTTP. It needs to send max-age=0 for twenty years in order to ensure that no one is locked out. But planning ahead twenty years is impossible. So for Twitter switching from twenty years to infinity doesn't add more risks.

Also, after all, we are not forcing websites to set non-expired HSTS. We just provide them an option to do so. It is their jobs to compare the pros and cons.

Best,
Xiaoyin
________________________________
From: Daniel Kahn Gillmor<mailto:[email-masked]>
Sent: ‎11/‎7/‎2014 10:05 AM
To: Xiaoyin Liu<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?

On 11/07/2014 01:56 AM, Xiaoyin Liu wrote:
> So I want to propose a update to RFC 6797 to define a new directive called
> "infinite" (or something else). When a UA sees this directive, max-age
> should be ignored and HSTS should always be enforced until users clear the
> cache or the server sends a valid STS header without "infinite" directive.
 [...]
> Any comments on this? Thanks!

The reason this wasn't included in the original spec was because of fear
of creating a "permanent footgun" -- that is, it's possible that the
HSTS header in a domain causes problems for the domain, and having those
problems never expire seems dangerous.

For example, the administrative overhead for maintaining X.509 certs
from the cartel might be too much for the organization at some point,
and they might want to opt out of it.  Or, Certificate Transparency
becomes dominant but fails to avoid full enumeration of X.509 hosts, and
the organization has includeSubdomains set but wants to have some hosts
whose names aren't enumerable publicly.  Alternately, the current domain
registrant may decide to transfer the domain to another registrant.
What happens then?

Perhaps the answers to these concerns are:

This is OK; the hassle of cert maintenance is not much greater than the
hassle of domain name registration; full zone enumeration can be solved
within an organization by registering a distinct zone in the DNS for the
non-enumerable hosts, and which doesn't have these properties; and we
should be moving to a world where zones are locked into being "secure
traffic only", and the "locked-secure" status of such a domain is one of
the many reputational factors that need to be weighed when considering a
zone transfer.

What do other folks think?

        --dkg

---

From: Tom Ritter <[email-masked]>
Date: Fri, 7 Nov 2014 18:13:37 -0600

On 7 November 2014 13:28, Xiaoyin Liu <[email-masked]> wrote:
> For instance, if Twitter wants to gracefully switch to HTTP. It needs to
> send max-age=0 for twenty years in order to ensure that no one is locked
> out. But planning ahead twenty years is impossible. So for Twitter switching
> from twenty years to infinity doesn't add more risks.

With something concrete, Paypal just jumped to 2 years:
https://twitter.com/equalsJeffH/status/530840852243832833 Maybe Jeff
can weigh in on what it took to get to that confidence level and
whether he/they would rather have 'infinite'.

-tom

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 11 Nov 2014 19:21:46 +0000

>whether he/they would rather have 'infinite'.

Short story - we¹d been running with paypal.com and www.paypal.com (but
not includesubdomains) on the preloaded list in Chrome for so long that it
didn¹t seem ricky at all. The lag was really just administrative -
deciding whether you need to test/re-test when you update the header since
the short value was in force for Firefox, Opera, and Safari but the
preloading was only enforced for Chrome.

In the end we just figured we¹d had the previous header for long enough
that upping the max-age to 2 years didn¹t seem risky.  In reality I should
probably have done it sooner.

- Andy