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

"Hodges, Jeff" <> Mon, 10 November 2014 19:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 643151A9166 for <>; Mon, 10 Nov 2014 11:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -20.602
X-Spam-Status: No, score=-20.602 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqftAX5ifjqC for <>; Mon, 10 Nov 2014 11:02:59 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4221C1A914F for <>; Mon, 10 Nov 2014 11:02:59 -0800 (PST)
DomainKey-Signature: s=paypalcorp;; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:user-agent: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:X-CFilter-Loop; b=FzXkgCLmYD2dsdu1CJGMl09bpw4vBBD/RUBQ6v3GgD20G9qE1Kx0Y55G yGklHYa/NnES7/zMPGSv+o2U9j+lDstmykcGxAy8JRD8Kk8aWVmrnxhP9 rQCXf7uD20CLFBjEZWLma6C2MyKd753yjC78fIH3PxquWeY/rSdUvGjSp I=;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=paypalcorp; t=1415646179; x=1447182179; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=S3LG37JRCsc/tCSMbzoPW27GbNRTVylSyVI0ZBhSFxg=; b=uU7svtGBEhzrs6bUKHTQElDbS7aVVPiUAiAK5vCR/uyJTa+3RFogWdrr wESjBXmFwuExnOU2IqgX6/SfWuxkGFQkML0BM6DylgzC0tcswVI2w0n4G jLQop24lWc2Caw5ygVbBOS6ME6uPjidkU4t6iYW3R+jnqgJFlaKukw2Ai E=;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="5.07,354,1413270000"; d="scan'208";a="76569372"
Received: from (HELO ([]) by with ESMTP; 10 Nov 2014 11:02:59 -0800
Received: from ([fe80::40c1:9cf7:d21e:46c]) by ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 12:02:58 -0700
From: "Hodges, Jeff" <>
To: Daniel Kahn Gillmor <>, Xiaoyin Liu <>, "" <>
Thread-Topic: [websec] HSTS: Infinite max-age to address NTP spoofing attack?
Thread-Index: AQHP+pw/D0s+sIxIsUWm8xW04n/gipxZ+buA
Date: Mon, 10 Nov 2014 19:02:57 +0000
Message-ID: <>
References: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Mon, 10 Nov 2014 19:03:01 -0000

On 11/7/14, 7:04 AM, "Daniel Kahn Gillmor" <> wrote:

>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
>> "infinite" (or something else). When a UA sees this directive, max-age
>> should be ignored and HSTS should always be enforced until users clear
>> cache or the server sends a valid STS header without "infinite"
> [...]
>> 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.

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).

>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?

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