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

"Hodges, Jeff" <jeff.hodges@paypal.com> Mon, 10 November 2014 19:03 UTC

Return-Path: <jeff.hodges@paypal.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643151A9166 for <websec@ietfa.amsl.com>; Mon, 10 Nov 2014 11:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -20.602
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqftAX5ifjqC for <websec@ietfa.amsl.com>; Mon, 10 Nov 2014 11:02:59 -0800 (PST)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4221C1A914F for <websec@ietf.org>; Mon, 10 Nov 2014 11:02:59 -0800 (PST)
DomainKey-Signature: s=paypalcorp; d=paypal.com; 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; d=paypal.com; i=@paypal.com; 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 den-vteml-004.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.120]) by den-mipot-001.corp.ebay.com with ESMTP; 10 Nov 2014 11:02:59 -0800
Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 12:02:58 -0700
From: "Hodges, Jeff" <jeff.hodges@paypal.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Xiaoyin Liu <xiaoyin.l@outlook.com>, "websec@ietf.org" <websec@ietf.org>
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: <D08597E7.3EB40%jeff.hodges@paypal.com>
References: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl> <545CDF98.8040706@fifthhorseman.net>
In-Reply-To: <545CDF98.8040706@fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [31.133.171.231]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4957DB4CCFBF574F8C6C2A21EF7A8D73@corp.ebay.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/1h7ktuC1NJK0So4KKMoMnPosiYY
Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 19:03:01 -0000

On 11/7/14, 7:04 AM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>; 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
>>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.

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.

=JeffH