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

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 7 Nov 2014 01:56:57 -0500

I recently read the slides "Bypassing HTTP Strict Transport Security" by 
Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack 
on HSTS is to allow sites to specify HSTS policies that never expire (i.e. 
infinite max-age), so that the enforcement of HSTS does not depend on the 
system time.
 
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.
 
The new header field will look like:
  Strict-Transport-Security: max-age=31536000; infinite
 
Of course, many websites will be unwilling to set infinite max-age, so this 
attack is not completely addressed. However, I think this new directive 
should help a lot, because some websites, especially those that need to 
send and receive sensitive information, such as online banking, are very 
unlikely to revert to HTTP in the future. Also, a very long max-age, such 
as 20 years used by Twitter, is effectively infinite, but long max-age is 
subject to the NTP attack, while an explicit "infinite" is not.
 
Any comments on this? Thanks!
 
Best,
Xiaoyin
[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Nov 2014 10:04:56 -0500

> 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: Hanno Böck <[email-masked]>
Date: Fri, 7 Nov 2014 16:14:52 +0100

I'm not sure what I think about an infinite HSTS timespan.

But I am pretty sure that no matter what, the underlying cause needs to
be fixed. A reliable time plays a role in a number of cases in TLS.
HPKP is basically vulnerable to the same kind of attack. Certificate
validity times/expirations are vulnerable.

After I was in the talk at BH I changed my systems to use tlsdated
instead of ntpd. That's the thing that should happen: We need to make
our time sources more reliable.

I was thinking about an idea I had during the talk: Maybe browsers
should add some time consistency checks? Basically two things would be
needed:
1. check for sane time on startup. Browsers check for updates,
CRLsets and other things anyway. They could just use the tls timestamp
of these requests and throw a warning if they differ significantly (I
don't want to nag users that don't set their time second-precise, but a
diff of more a day could give a warning)
2. check for consistency while running. There could be periodical
checks and if the time does large jumps also throw a warning.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: "Hodges, Jeff" <[email-masked]>
Date: Mon, 10 Nov 2014 19:02:57 +0000

>problems never expire seems dangerous.

Agreed, tho without going back thru all that history, I don't recall our
ever discussing having an HSTS Policy that never expires (but whatever).

>What do other folks think?

Yes, there's various deployment/operational considerations where one may
want/need to signal the Uas to forget about a particular HSTS Policy.

=JeffH

---

From: "Hodges, Jeff" <[email-masked]>
Date: Mon, 10 Nov 2014 19:03:01 +0000

On 11/7/14, 7:14 AM, "Hanno Böck" <[email-masked]> wrote:

>be fixed. 

Strongly agreed.

>A reliable time plays a role in a number of cases in TLS.

Yes, there's a plethora of protocols that contain timestampes of one sort
or another. Thus to some degree or another, they rely upo systems' time,
and if that time is corrupted by an attacker then the system and its users
may be in trouble. 

I don't think it's feasible, or in all or most cases a good design, to go
back and 'patch' those protocols to try to guard against NTP-based attacks
(as one example of how system time may be corrupted), rather, platforms
should (as AGL noted in a earlier thread "NTP vs. HSTS" on [1]) "fix the
clock" (I.e. Address NTP and other clock vulns).

=JeffH

[1] W3C Web App Security WG <[email-masked]>
    http://lists.w3.org/Archives/Public/public-webappsec/

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 10 Nov 2014 09:49:13 -1000

> clock" (I.e. Address NTP and other clock vulns).

<wg chair hat= off>
I agree with Jeff. It would better to aim fixing the clock issue (or the 
relying on fake clocks), than trying to give "infinite" to all kinds of 
protocol parameters.
Tobias

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Nov 2014 10:09:39 -1000

> On Nov 10, 2014, at 9:49 AM, Tobias Gondrom <[email-masked]> wrote:
> 
> I agree with Jeff. It would better to aim fixing the clock issue (or the relying on fake clocks), than trying to give "infinite" to all kinds of protocol parameters.
> Tobias

+1 

And DKG has mentioned not wanting to create a permanent foot-gun. That is right, but I don’t think telling management “our website is bricked forever” is any better than telling them that “our website is bricked for two years”.

Besides, if you move so far in the future that a 1-year or 2-year HSTS header expires, you’re going to see expired certificates anyway.

Yoav