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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 07 November 2014 15:05 UTC

Return-Path: <dkg@fifthhorseman.net>
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 462721A8716 for <websec@ietfa.amsl.com>; Fri, 7 Nov 2014 07:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sKdLa8-nNG-0 for <websec@ietfa.amsl.com>; Fri, 7 Nov 2014 07:05:12 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9B1A871F for <websec@ietf.org>; Fri, 7 Nov 2014 07:05:00 -0800 (PST)
Received: from [10.70.10.71] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 31B3AF984; Fri, 7 Nov 2014 10:04:57 -0500 (EST)
Message-ID: <545CDF98.8040706@fifthhorseman.net>
Date: Fri, 07 Nov 2014 10:04:56 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0
MIME-Version: 1.0
To: Xiaoyin Liu <xiaoyin.l@outlook.com>, "websec@ietf.org" <websec@ietf.org>
References: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl>
In-Reply-To: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dd10bOjPfdka4FqTOi2EeGsBCt29fcr8U"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/PSPYKU87uZVGAhSx_OUsl6VveOI
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: Fri, 07 Nov 2014 15:05:15 -0000

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