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

Xiaoyin Liu <> Fri, 07 November 2014 19:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 10CDD1A0358 for <>; Fri, 7 Nov 2014 11:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CWphgxVmNJt1 for <>; Fri, 7 Nov 2014 11:28:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E7A71A01EA for <>; Fri, 7 Nov 2014 11:28:56 -0800 (PST)
Received: from BAY405-EAS153 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 7 Nov 2014 11:28:56 -0800
X-TMN: [tlWgslNNv2DX4nkadNVQuHH3u+R90wpm]
X-Originating-Email: []
Message-ID: <BAY405-EAS15381E2B86B576B335C1341FF850@phx.gbl>
Content-Type: multipart/alternative; boundary="_b311bc26-c51a-4cd4-a8cc-cc29fa7b51ef_"
MIME-Version: 1.0
To: Daniel Kahn Gillmor <>, "" <>
From: Xiaoyin Liu <>
Date: Fri, 7 Nov 2014 14:28:42 -0500
X-OriginalArrivalTime: 07 Nov 2014 19:28:56.0333 (UTC) FILETIME=[12845BD0:01CFFAC1]
Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Nov 2014 19:28:58 -0000

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.

From: Daniel Kahn Gillmor<>
Sent: ‎11/‎7/‎2014 10:05 AM
To: Xiaoyin Liu<>;<>
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?