From xiaoyin.l@outlook.com Thu Nov 6 22:56:59 2014 Return-Path: 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 038051ACEF5 for ; Thu, 6 Nov 2014 22:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHmD9EhQbywJ for ; Thu, 6 Nov 2014 22:56:57 -0800 (PST) Received: from BAY004-OMC1S16.hotmail.com (bay004-omc1s16.hotmail.com [65.54.190.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878101A1A6D for ; Thu, 6 Nov 2014 22:56:57 -0800 (PST) Received: from BAY180-W65 ([65.54.190.59]) by BAY004-OMC1S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 6 Nov 2014 22:56:57 -0800 X-TMN: [CYJmumVmTp6kTvA2HSOanq76SHL/R84D] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_d96793a6-5a22-49d4-ac03-13467988ad22_" From: Xiaoyin Liu To: "websec@ietf.org" Date: Fri, 7 Nov 2014 01:56:57 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2014 06:56:57.0470 (UTC) FILETIME=[059439E0:01CFFA58] Archived-At: http://mailarchive.ietf.org/arch/msg/websec/6jUTYElPw_TukEdyXyMho26h4Bo Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:00:43 -0000 --_d96793a6-5a22-49d4-ac03-13467988ad22_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I recently read the slides "Bypassing HTTP Strict Transport Security" by=20 Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack=20 on HSTS is to allow sites to specify HSTS policies that never expire (i.e.= =20 infinite max-age)=2C so that the enforcement of HSTS does not depend on the= =20 system time. =20 So I want to propose a update to RFC 6797 to define a new directive called= =20 "infinite" (or something else). When a UA sees this directive=2C max-age=20 should be ignored and HSTS should always be enforced until users clear the= =20 cache or the server sends a valid STS header without "infinite" directive. =20 The new header field will look like: Strict-Transport-Security: max-age=3D31536000=3B infinite =20 Of course=2C many websites will be unwilling to set infinite max-age=2C so = this=20 attack is not completely addressed. However=2C I think this new directive=20 should help a lot=2C because some websites=2C especially those that need to= =20 send and receive sensitive information=2C such as online banking=2C are ver= y=20 unlikely to revert to HTTP in the future. Also=2C a very long max-age=2C su= ch=20 as 20 years used by Twitter=2C is effectively infinite=2C but long max-age = is=20 subject to the NTP attack=2C while an explicit "infinite" is not. =20 Any comments on this? Thanks! =20 Best=2C Xiaoyin [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTT= P-Strict-Transport-Security-wp.pdf = --_d96793a6-5a22-49d4-ac03-13467988ad22_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3BI recently read the slid= es "Bypassing HTTP Strict Transport Security" by
Jose Selvi.[1] It seem= s 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-ag= e)=2C so that the enforcement of HSTS does not depend on the
system tim= e.
 =3B
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 d= irective=2C max-age
should be ignored and HSTS should always be enforce= d until users clear the
cache or the server sends a valid STS header wi= thout "infinite" directive.
 =3B
The new header field will look l= ike:
 =3B Strict-Transport-Security: max-age=3D31536000=3B infinite<= BR> =3B
Of course=2C many websites will be unwilling to set infinite= max-age=2C so this
attack is not completely addressed. However=2C I th= ink this new directive
should help a lot=2C because some websites=2C es= pecially those that need to
send and receive sensitive information=2C s= uch as online banking=2C are very
unlikely to revert to HTTP in the fut= ure. Also=2C a very long max-age=2C such
as 20 years used by Twitter=2C= is effectively infinite=2C but long max-age is
subject to the NTP atta= ck=2C while an explicit "infinite" is not.
 =3B
Any comments on t= his? Thanks!
 =3B
Best=2C
Xiaoyin
[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-S= elvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
= --_d96793a6-5a22-49d4-ac03-13467988ad22_-- From nobody Fri Nov 7 07:05:17 2014 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: Xiaoyin Liu , "websec@ietf.org" References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:05:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dd10bOjPfdka4FqTOi2EeGsBCt29fcr8U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 cal= led=20 > "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=20 > cache or the server sends a valid STS header without "infinite" directi= ve. [...] > 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 --dd10bOjPfdka4FqTOi2EeGsBCt29fcr8U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUXN+YXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpc0AMQAMBzplMTqKAnvh0gDqJwFcpS 5TYskgOkvHw5BL+HSCliwMJQENYPanQfhDKlcjf//sATj29SKV+wClk6zmVVhudV sd95gti8m7rWZ+A2tioJ3oJF+lI0V8q2HcJwy1JanHx3i3i5AKQMTw5ysmvgaLyg BfrIJ8TpWvhgLyQqstS3JCHGUTJkc4OBv1BxGr9jGr0fjwfiiqsWwe1eJkee9Swl 7CqHfTmJhXb1tZpR3T+oMApgNN5Yab/+roeF1ayVBCuNdLXjKG2rfeCBYuOn2Szg wMDM1W9NrANvtlg6cYQDu6uO41sWKdf5W2zfAbACErURbGWhuIawFn8uMaMqJ0j6 zK1WTY+D17zgg/vgM7AOxhd/KVMV3+7ZLJHAOLW5kH+qSyYKVkDvImfrCV5d5wMe edV7wA3Inu7oYCAaItC81dufOsn4rmKztWh58xqFDWvy10Ne43iOJWMn5sXjdVoq posQ51s6ePM5dWDyIHUcm10TQm8C0kSCeMSLev3C9Wtq2uHwvkrrLL2F8xBFHoCh huuhg4HxIRLfCR5Bw9HncEWwLL4fmNk8UQJN7RN2j1zpjwV5RqdCbxCqqwFaJAeZ Z7/bXm7yQB1s2mEFFjB5dQrcjEvFT0BKzgzuW/KCGuR8+fF1aroOxLxBzA57a0WK uBGNES5/6lpvrvL+MJPz =fiI5 -----END PGP SIGNATURE----- --dd10bOjPfdka4FqTOi2EeGsBCt29fcr8U-- From nobody Fri Nov 7 07:15:07 2014 Return-Path: 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 862311A8744 for ; Fri, 7 Nov 2014 07:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 7ihoBQy7G__P for ; Fri, 7 Nov 2014 07:14:55 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F98B1A86DE for ; Fri, 7 Nov 2014 07:14:55 -0800 (PST) Received: from pc (ip25053198.dynamic.kabel-deutschland.de [::ffff:37.5.49.152]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 07 Nov 2014 16:14:53 +0100 id 0000000000000027.00000000545CE1ED.00007C4A Date: Fri, 7 Nov 2014 16:14:52 +0100 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: websec@ietf.org Message-ID: <20141107161452.2b834f23@pc> In-Reply-To: References: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-31818-1415373293-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/iAaHuf3l-KSjgHppi4ItpovAoNM 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:15:03 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-31818-1415373293-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-31818-1415373293-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUXOHsAAoJEKWIAHK7tR5CfvcP/27IY9kI8h/qjL340mC4rIK9 quVF3EiHt98YB+kkBlm0EVgsJZXm0Bsm/lsH6MpRMgQ2/oNIUJC1uALK1ZQciVgY yNLLUVOH9UJqlecmlJbfrRRVTAaTAUyyivhfnsiElYDw3qHlRvC9D+Tkp2CPl+AB SwXYK/1UWEm1XYynG88An7TECN4PEUPcFQha+1n9ltwf2VUGhG+Ko/cvGV26L2Hc kTD48w/HQ44rWzWXiUXM5te2/AouNeQByRKJt90gqUMjaHt0VeRxQNBGzPwo/Kpy 12cW2XYOQlEUDNUXMn29Ky/5kmGE2CQEfyQTXEky4D+jO4miY3FM+eU9mXcCEpYx sJHzpTCFChUDFX0ERJ6xyRh5kpfRXElonPCToJ6bqwc/p8rMSfEjRYOhkZA3+w3/ Sk+g4zeR7kcI9VV2LKIyMEZHY3p+o3zhijSNLYvh9BLN4JaK7H/aUu7kelIab0Rf Mo2v1uHh+Z2Y+dhRqil4WX8q0wcbfb/Lxh0J5u364LK0B/awp/hSUb4E9/cnxVsK VFv9Hitsucpv7AIXN0nHMc+ALKbxJSYjKfUD6aXmizCYkKcot989Jo4fFGXfXU4J sZeaYGrojBjrRTE/lr0k9+CGttJ0YzUCgnsciCrh+bLWeAlnCiZTfHxzzsADSkMU rzRLMJDXGIyrFcsHFfAs =pDxE -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-31818-1415373293-0001-2-- From nobody Fri Nov 7 11:28:59 2014 Return-Path: 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 10CDD1A0358 for ; Fri, 7 Nov 2014 11:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWphgxVmNJt1 for ; Fri, 7 Nov 2014 11:28:56 -0800 (PST) Received: from BAY004-OMC3S24.hotmail.com (bay004-omc3s24.hotmail.com [65.54.190.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7A71A01EA for ; Fri, 7 Nov 2014 11:28:56 -0800 (PST) Received: from BAY405-EAS153 ([65.54.190.187]) by BAY004-OMC3S24.hotmail.com 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: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_b311bc26-c51a-4cd4-a8cc-cc29fa7b51ef_" MIME-Version: 1.0 To: Daniel Kahn Gillmor , "websec@ietf.org" 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] Archived-At: http://mailarchive.ietf.org/arch/msg/websec/SKtaVjBVi2SJ7vqsYR_RohW-SNU 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:28:58 -0000 --_b311bc26-c51a-4cd4-a8cc-cc29fa7b51ef_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thank you for comment! I agree with you that setting a HSTS policy that nev= er expires might be somewhat risky=2C 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 t= he max-age. So it's possible that sites specify a very long time span. Howe= ver=2C all the concerns of infinite HSTS also apply to extremely-long HSTS. For instance=2C if Twitter wants to gracefully switch to HTTP. It needs to = send max-age=3D0 for twenty years in order to ensure that no one is locked = out. But planning ahead twenty years is impossible. So for Twitter switchin= g from twenty years to infinity doesn't add more risks. Also=2C after all=2C we are not forcing websites to set non-expired HSTS. W= e just provide them an option to do so. It is their jobs to compare the pro= s and cons. Best=2C Xiaoyin ________________________________ From: Daniel Kahn Gillmor Sent: =E2=80=8E11/=E2=80=8E7/=E2=80=8E2014 10:05 AM To: Xiaoyin Liu=3B websec@ietf.org Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack= ? On 11/07/2014 01:56 AM=2C Xiaoyin Liu wrote: > So I want to propose a update to RFC 6797 to define a new directive calle= d > "infinite" (or something else). When a UA sees this directive=2C max-age > should be ignored and HSTS should always be enforced until users clear th= e > 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=2C it's possible that the HSTS header in a domain causes problems for the domain=2C and having those problems never expire seems dangerous. For example=2C the administrative overhead for maintaining X.509 certs from the cartel might be too much for the organization at some point=2C and they might want to opt out of it. Or=2C Certificate Transparency becomes dominant but fails to avoid full enumeration of X.509 hosts=2C and the organization has includeSubdomains set but wants to have some hosts whose names aren't enumerable publicly. Alternately=2C 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=3B the hassle of cert maintenance is not much greater than the hassle of domain name registration=3B full zone enumeration can be solved within an organization by registering a distinct zone in the DNS for the non-enumerable hosts=2C and which doesn't have these properties=3B and we should be moving to a world where zones are locked into being "secure traffic only"=2C 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 --_b311bc26-c51a-4cd4-a8cc-cc29fa7b51ef_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Than= k you for comment! I agree with you that setting a HSTS policy that never e= xpires might be somewhat risky=2C 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 t= he max-age. So it's possible that sites specify a very long time span. Howe= ver=2C all the concerns of infinite HSTS also apply to extremely-long HSTS.=

For instance=2C if Twitter wants to gracefully switch to HTTP. It needs to = send max-age=3D0 for twenty years in order to ensure that no one is locked = out. But planning ahead twenty years is impossible. So for Twitter switchin= g from twenty years to infinity doesn't add more risks.

Also=2C after all=2C we are not forcing websites to set non-expired HSTS. W= e just provide them an option to do so. It is their jobs to compare the pro= s and cons.

Best=2C
Xiaoyin

From: Daniel Kahn Gillmor
Sent: =E2=80=8E11/=E2=80=8E7/=E2=80=8E2014 10:05 AM
To: Xiaoyin Liu=3B websec@ietf.org
Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?

On 11/07/2014 01:56 AM=2C Xiaoyin Liu wrote:
>=3B So I want to propose a update to RFC 6797 to define a new directive = called
>=3B "=3Binfinite"=3B (or something else). When a UA sees this di= rective=2C max-age
>=3B should be ignored and HSTS should always be enforced until users cle= ar the
>=3B cache or the server sends a valid STS header without "=3Binfinit= e"=3B directive.
 =3B[...]
>=3B Any comments on this? Thanks!

The reason this wasn't included in the original spec was because of fear of creating a "=3Bpermanent footgun"=3B -- that is=2C it's possible= that the
HSTS header in a domain causes problems for the domain=2C and having those<= br> problems never expire seems dangerous.

For example=2C the administrative overhead for maintaining X.509 certs
from the cartel might be too much for the organization at some point=2C
and they might want to opt out of it. =3B Or=2C Certificate Transparenc= y
becomes dominant but fails to avoid full enumeration of X.509 hosts=2C and<= br> the organization has includeSubdomains set but wants to have some hosts
whose names aren't enumerable publicly. =3B Alternately=2C 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=3B the hassle of cert maintenance is not much greater than the hassle of domain name registration=3B full zone enumeration can be solved within an organization by registering a distinct zone in the DNS for the non-enumerable hosts=2C and which doesn't have these properties=3B and we should be moving to a world where zones are locked into being "=3Bsecur= e
traffic only"=3B=2C and the "=3Blocked-secure"=3B status of suc= h a domain is one of
the many reputational factors that need to be weighed when considering a zone transfer.

What do other folks think?

 =3B =3B =3B =3B =3B =3B =3B --dkg

--_b311bc26-c51a-4cd4-a8cc-cc29fa7b51ef_-- From nobody Fri Nov 7 16:14:02 2014 Return-Path: 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 A62681A0066 for ; Fri, 7 Nov 2014 16:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no 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 CYunpsR1IRFm for ; Fri, 7 Nov 2014 16:13:58 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2CE1A000E for ; Fri, 7 Nov 2014 16:13:58 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so6894607iga.2 for ; Fri, 07 Nov 2014 16:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PbaF3CDigeavFdCscKSMFH5vZ3e3YkQJfdwipNq7+3A=; b=pn+ICUtJHY9eeCoTZXZ6XMj+FjpvCmyl5cEnFB9/v/nXH6OpKEDzNaTPBFz4TU7CoF TapSuKG0/Jr4eJXQAxCdPp8AwP6XHc8fkPXZUOL3TpiqddBGwzpsqZRaePaN3so/n1qE I6mEQDGDXH9OE0QwivvLt0wPudt4xy2UwaiiI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PbaF3CDigeavFdCscKSMFH5vZ3e3YkQJfdwipNq7+3A=; b=jJ8RrexWhGgyev6wCHAdnq3CZ2hHzEyf6iPBGem76pXgK4/5aQo583clkoATCMpE6b lwvVme/uAX87ylCSbJmFKpuMBxEMpN9cwDyfP6ZFBk8csG9sa/HisSBFjah+pI1irhVa f3MHNB/g9T0bO1dIs7iegdhi4W3yocyIB+gnIzZ163EjCZ8yVdBwxGNl3fAZhJL0nbgn QwfpsDe54DtTBcFRfnQFRbls/uRTLg9DptW3OF5agK6mlPSuccjDOmeGOiKWfCJuxUVv 6gabuzVda6jXmKDHog+OJcW7C6ovZpKdoQLzV6EeYSLmJTFE2Mty37ADIaFtVQD3wgXf XhDQ== X-Gm-Message-State: ALoCoQnAa+b2OpX3RnrbV6cHmHM7YotUFiWxXUCEBJlUtjv/Jb2GRM5JVh2F1laLXLFDMgQ7ctYO X-Received: by 10.107.3.101 with SMTP id 98mr16659798iod.25.1415405637695; Fri, 07 Nov 2014 16:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.170.73 with HTTP; Fri, 7 Nov 2014 16:13:37 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Fri, 7 Nov 2014 18:13:37 -0600 Message-ID: To: Xiaoyin Liu Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/tPCgxo8TJDKDV8zj7AP2eewF6no Cc: "websec@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:14:01 -0000 On 7 November 2014 13:28, Xiaoyin Liu wrote: > 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. With something concrete, Paypal just jumped to 2 years: https://twitter.com/equalsJeffH/status/530840852243832833 Maybe Jeff can weigh in on what it took to get to that confidence level and whether he/they would rather have 'infinite'. -tom From nobody Mon Nov 10 11:03:03 2014 Return-Path: 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 ; 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 ; 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 ; 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" To: Daniel Kahn Gillmor , Xiaoyin Liu , "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: References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:03:01 -0000 T24gMTEvNy8xNCwgNzowNCBBTSwgIkRhbmllbCBLYWhuIEdpbGxtb3IiIDxka2dAZmlmdGhob3Jz ZW1hbi5uZXQ+IHdyb3RlOg0KDQo+T24gMTEvMDcvMjAxNCAwMTo1NiBBTSwgWGlhb3lpbiBMaXUg d3JvdGU6DQo+PiBTbyBJIHdhbnQgdG8gcHJvcG9zZSBhIHVwZGF0ZSB0byBSRkMgNjc5NyB0byBk ZWZpbmUgYSBuZXcgZGlyZWN0aXZlDQo+PmNhbGxlZCANCj4+ICJpbmZpbml0ZSIgKG9yIHNvbWV0 aGluZyBlbHNlKS4gV2hlbiBhIFVBIHNlZXMgdGhpcyBkaXJlY3RpdmUsIG1heC1hZ2UNCj4+IHNo b3VsZCBiZSBpZ25vcmVkIGFuZCBIU1RTIHNob3VsZCBhbHdheXMgYmUgZW5mb3JjZWQgdW50aWwg dXNlcnMgY2xlYXINCj4+dGhlIA0KPj4gY2FjaGUgb3IgdGhlIHNlcnZlciBzZW5kcyBhIHZhbGlk IFNUUyBoZWFkZXIgd2l0aG91dCAiaW5maW5pdGUiDQo+PmRpcmVjdGl2ZS4NCj4gWy4uLl0NCj4+ IEFueSBjb21tZW50cyBvbiB0aGlzPyBUaGFua3MhDQo+DQo+VGhlIHJlYXNvbiB0aGlzIHdhc24n dCBpbmNsdWRlZCBpbiB0aGUgb3JpZ2luYWwgc3BlYyB3YXMgYmVjYXVzZSBvZiBmZWFyDQo+b2Yg Y3JlYXRpbmcgYSAicGVybWFuZW50IGZvb3RndW4iIC0tIHRoYXQgaXMsIGl0J3MgcG9zc2libGUg dGhhdCB0aGUNCj5IU1RTIGhlYWRlciBpbiBhIGRvbWFpbiBjYXVzZXMgcHJvYmxlbXMgZm9yIHRo ZSBkb21haW4sIGFuZCBoYXZpbmcgdGhvc2UNCj5wcm9ibGVtcyBuZXZlciBleHBpcmUgc2VlbXMg ZGFuZ2Vyb3VzLg0KDQpBZ3JlZWQsIHRobyB3aXRob3V0IGdvaW5nIGJhY2sgdGhydSBhbGwgdGhh dCBoaXN0b3J5LCBJIGRvbid0IHJlY2FsbCBvdXINCmV2ZXIgZGlzY3Vzc2luZyBoYXZpbmcgYW4g SFNUUyBQb2xpY3kgdGhhdCBuZXZlciBleHBpcmVzIChidXQgd2hhdGV2ZXIpLg0KDQoNCj5Gb3Ig ZXhhbXBsZSwgdGhlIGFkbWluaXN0cmF0aXZlIG92ZXJoZWFkIGZvciBtYWludGFpbmluZyBYLjUw OSBjZXJ0cw0KPmZyb20gdGhlIGNhcnRlbCBtaWdodCBiZSB0b28gbXVjaCBmb3IgdGhlIG9yZ2Fu aXphdGlvbiBhdCBzb21lIHBvaW50LA0KPmFuZCB0aGV5IG1pZ2h0IHdhbnQgdG8gb3B0IG91dCBv ZiBpdC4gIE9yLCBDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3kNCj5iZWNvbWVzIGRvbWluYW50IGJ1 dCBmYWlscyB0byBhdm9pZCBmdWxsIGVudW1lcmF0aW9uIG9mIFguNTA5IGhvc3RzLCBhbmQNCj50 aGUgb3JnYW5pemF0aW9uIGhhcyBpbmNsdWRlU3ViZG9tYWlucyBzZXQgYnV0IHdhbnRzIHRvIGhh dmUgc29tZSBob3N0cw0KPndob3NlIG5hbWVzIGFyZW4ndCBlbnVtZXJhYmxlIHB1YmxpY2x5LiAg QWx0ZXJuYXRlbHksIHRoZSBjdXJyZW50IGRvbWFpbg0KPnJlZ2lzdHJhbnQgbWF5IGRlY2lkZSB0 byB0cmFuc2ZlciB0aGUgZG9tYWluIHRvIGFub3RoZXIgcmVnaXN0cmFudC4NCj5XaGF0IGhhcHBl bnMgdGhlbj8NCj4NCj5QZXJoYXBzIHRoZSBhbnN3ZXJzIHRvIHRoZXNlIGNvbmNlcm5zIGFyZToN Cj4NCj5UaGlzIGlzIE9LOyB0aGUgaGFzc2xlIG9mIGNlcnQgbWFpbnRlbmFuY2UgaXMgbm90IG11 Y2ggZ3JlYXRlciB0aGFuIHRoZQ0KPmhhc3NsZSBvZiBkb21haW4gbmFtZSByZWdpc3RyYXRpb247 IGZ1bGwgem9uZSBlbnVtZXJhdGlvbiBjYW4gYmUgc29sdmVkDQo+d2l0aGluIGFuIG9yZ2FuaXph dGlvbiBieSByZWdpc3RlcmluZyBhIGRpc3RpbmN0IHpvbmUgaW4gdGhlIEROUyBmb3IgdGhlDQo+ bm9uLWVudW1lcmFibGUgaG9zdHMsIGFuZCB3aGljaCBkb2Vzbid0IGhhdmUgdGhlc2UgcHJvcGVy dGllczsgYW5kIHdlDQo+c2hvdWxkIGJlIG1vdmluZyB0byBhIHdvcmxkIHdoZXJlIHpvbmVzIGFy ZSBsb2NrZWQgaW50byBiZWluZyAic2VjdXJlDQo+dHJhZmZpYyBvbmx5IiwgYW5kIHRoZSAibG9j a2VkLXNlY3VyZSIgc3RhdHVzIG9mIHN1Y2ggYSBkb21haW4gaXMgb25lIG9mDQo+dGhlIG1hbnkg cmVwdXRhdGlvbmFsIGZhY3RvcnMgdGhhdCBuZWVkIHRvIGJlIHdlaWdoZWQgd2hlbiBjb25zaWRl cmluZyBhDQo+em9uZSB0cmFuc2Zlci4NCj4NCj5XaGF0IGRvIG90aGVyIGZvbGtzIHRoaW5rPw0K DQpZZXMsIHRoZXJlJ3MgdmFyaW91cyBkZXBsb3ltZW50L29wZXJhdGlvbmFsIGNvbnNpZGVyYXRp b25zIHdoZXJlIG9uZSBtYXkNCndhbnQvbmVlZCB0byBzaWduYWwgdGhlIFVhcyB0byBmb3JnZXQg YWJvdXQgYSBwYXJ0aWN1bGFyIEhTVFMgUG9saWN5Lg0KDQo9SmVmZkgNCg0KDQo= From nobody Mon Nov 10 11:03:08 2014 Return-Path: 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 B151D1A916F for ; Mon, 10 Nov 2014 11:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.901 X-Spam-Level: X-Spam-Status: No, score=-19.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 TjOskzajaPkn for ; Mon, 10 Nov 2014 11:03:03 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674991A916D for ; Mon, 10 Nov 2014 11:03:02 -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=FN81LRwHL8JB8zAqRMW8kbfiguNxR5zReeZS91KhIOZ/7Oxr+Ck8qjyP Ao7ZZnj6oMdxzyVdWA1dYXf94L1YWrC01CeoBVS3QEe1LVF372Kijybav RAqXrH5LMCwoYLRbuzbb/pXYVm7Y+EGKWLorY/mh8OW0gfm40hYttQVIP Y=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1415646182; x=1447182182; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XudC/oP0QEh1qp5eqcQuC5Y7GRUepLohIrSmO1JAobQ=; b=fruf3ZCshVCFNsVHI0Ij0ha0J8jSffJxbb4elJ3lRkfm7b7n++c+BjSJ oKZRirwauVT0X6Sea4jp7oelDNiulQV/MVzq7BydBj5n6aU/uf4oJfk2W EF4YaIgj/7izVvvdheuLGdJq+J6yBYJ6O5FEl/d79pBKaKUkOrWxBi8d9 c=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.07,354,1413270000"; d="scan'208";a="76886188" Received: from den-vteml-003.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.119]) by den-mipot-002.corp.ebay.com with ESMTP; 10 Nov 2014 11:03:01 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 12:03:01 -0700 From: "Hodges, Jeff" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "websec@ietf.org" Thread-Topic: [websec] HSTS: Infinite max-age to address NTP spoofing attack? Thread-Index: AQHP+p231f2A8DX2l0GbTYTfBe4LvZxZ+bwA Date: Mon, 10 Nov 2014 19:03:01 +0000 Message-ID: References: <20141107161452.2b834f23@pc> In-Reply-To: <20141107161452.2b834f23@pc> 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: <2FBEF13409B4514E9EF5AFBBE4F7082D@corp.ebay.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/websec/0BGtGFZCpqOf6CBPFpWgqWKzB88 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:03:05 -0000 T24gMTEvNy8xNCwgNzoxNCBBTSwgIkhhbm5vIELDtmNrIiA8aGFubm9AaGJvZWNrLmRlPiB3cm90 ZToNCg0KPg0KPkJ1dCBJIGFtIHByZXR0eSBzdXJlIHRoYXQgbm8gbWF0dGVyIHdoYXQsIHRoZSB1 bmRlcmx5aW5nIGNhdXNlIG5lZWRzIHRvDQo+YmUgZml4ZWQuIA0KDQpTdHJvbmdseSBhZ3JlZWQu DQoNCj5BIHJlbGlhYmxlIHRpbWUgcGxheXMgYSByb2xlIGluIGEgbnVtYmVyIG9mIGNhc2VzIGlu IFRMUy4NCj5IUEtQIGlzIGJhc2ljYWxseSB2dWxuZXJhYmxlIHRvIHRoZSBzYW1lIGtpbmQgb2Yg YXR0YWNrLiBDZXJ0aWZpY2F0ZQ0KPnZhbGlkaXR5IHRpbWVzL2V4cGlyYXRpb25zIGFyZSB2dWxu ZXJhYmxlLg0KDQpZZXMsIHRoZXJlJ3MgYSBwbGV0aG9yYSBvZiBwcm90b2NvbHMgdGhhdCBjb250 YWluIHRpbWVzdGFtcGVzIG9mIG9uZSBzb3J0DQpvciBhbm90aGVyLiBUaHVzIHRvIHNvbWUgZGVn cmVlIG9yIGFub3RoZXIsIHRoZXkgcmVseSB1cG8gc3lzdGVtcycgdGltZSwNCmFuZCBpZiB0aGF0 IHRpbWUgaXMgY29ycnVwdGVkIGJ5IGFuIGF0dGFja2VyIHRoZW4gdGhlIHN5c3RlbSBhbmQgaXRz IHVzZXJzDQptYXkgYmUgaW4gdHJvdWJsZS4gDQoNCkkgZG9uJ3QgdGhpbmsgaXQncyBmZWFzaWJs ZSwgb3IgaW4gYWxsIG9yIG1vc3QgY2FzZXMgYSBnb29kIGRlc2lnbiwgdG8gZ28NCmJhY2sgYW5k ICdwYXRjaCcgdGhvc2UgcHJvdG9jb2xzIHRvIHRyeSB0byBndWFyZCBhZ2FpbnN0IE5UUC1iYXNl ZCBhdHRhY2tzDQooYXMgb25lIGV4YW1wbGUgb2YgaG93IHN5c3RlbSB0aW1lIG1heSBiZSBjb3Jy dXB0ZWQpLCByYXRoZXIsIHBsYXRmb3Jtcw0Kc2hvdWxkIChhcyBBR0wgbm90ZWQgaW4gYSBlYXJs aWVyIHRocmVhZCAiTlRQIHZzLiBIU1RTIiBvbiBbMV0pICJmaXggdGhlDQpjbG9jayIgKEkuZS4g QWRkcmVzcyBOVFAgYW5kIG90aGVyIGNsb2NrIHZ1bG5zKS4NCg0KPUplZmZIDQoNClsxXSBXM0Mg V2ViIEFwcCBTZWN1cml0eSBXRyA8cHVibGljLXdlYmFwcHNlY0B3My5vcmc+DQogICAgaHR0cDov L2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLXdlYmFwcHNlYy8NCg0KDQoNCg0K From nobody Mon Nov 10 11:49:20 2014 Return-Path: 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 D886C1AC446 for ; Mon, 10 Nov 2014 11:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.949 X-Spam-Level: X-Spam-Status: No, score=-94.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MANGLED_BACK=2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 8-3F4Kv2hMYY for ; Mon, 10 Nov 2014 11:49:17 -0800 (PST) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EF71ACCED for ; Mon, 10 Nov 2014 11:49:17 -0800 (PST) Received: from [IPv6:2001:67c:1231:998:7833:95ce:d3be:dc35] (unknown [31.130.238.66]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 7A5D362F8F; Mon, 10 Nov 2014 20:49:15 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=yJRzG1+wLPwHEW1cprteBUUN97l6VjBy4KiH+08ejnVqkGNPbHM4Hj8I3PLBIDnLOrLwwEl1FIjSG4c13fDAUga7E67WuvonkHBX9AgeLivqbUxks0js+plB/jrSTn9zUDEMLRcWzl/Fnet8Iny3lV04eGtUWzH8Kj5SshH88bE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <546116B9.4030900@gondrom.org> Date: Mon, 10 Nov 2014 09:49:13 -1000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: jeff.hodges@paypal.com, hanno@hboeck.de, websec@ietf.org References: <20141107161452.2b834f23@pc> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/7u6SWSHWBwBO7LOZW55ALWQTcuA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:49:19 -0000 On 10/11/14 09:03, Hodges, Jeff wrote: > On 11/7/14, 7:14 AM, "Hanno Böck" wrote: > >> But I am pretty sure that no matter what, the underlying cause needs to >> be fixed. > Strongly agreed. > >> 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. > 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). 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 > =JeffH > > [1] W3C Web App Security WG > http://lists.w3.org/Archives/Public/public-webappsec/ > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Mon Nov 10 12:10:13 2014 Return-Path: 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 2F73A1ACDB7 for ; Mon, 10 Nov 2014 12:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no 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 XeozrhT8V5PV for ; Mon, 10 Nov 2014 12:10:03 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABDD1A9073 for ; Mon, 10 Nov 2014 12:09:46 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so11811415wiw.9 for ; Mon, 10 Nov 2014 12:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ALXfoh5yuBPdABtkMlILiZZ8c8VWE31aqRINlpDVnw8=; b=d1gG022d5ve4cxJJBqKgXhqrtUk8YH28/0o5JOEx4iv18r4VZ5nepqepoPgPz2BhTZ kBkz7Q5Bb1uml6lCmFrqT5q6EgnAS797h2sqsx0qKr3heMIMafOLhgho7JPs7OjdNMx2 zaRIjX5rLWsqRQ8ToRFRaT+zcKG2r8adlVrMTL7CXSsVU1KP/+qMqwBBwcJVxVTmhahm oWAX2BQ4ZBrfxwJlaaqOc4hi7tf/9N7ZmgnTQFesANrabmqMoGGfdzD8DECJvkUONKkH Z5DBQYBnFhuIk7r2XKuagt0kehAGZrHDB1aYDV8mhiy+pe1xYbfBkDnJELiUV24iiYEy OBUQ== X-Received: by 10.194.190.19 with SMTP id gm19mr46613944wjc.51.1415650184483; Mon, 10 Nov 2014 12:09:44 -0800 (PST) Received: from t2001067c0370016001435d87602e7faf.wireless.v6.meeting.ietf.org (t2001067c0370016001435d87602e7faf.wireless.v6.meeting.ietf.org. [2001:67c:370:160:143:5d87:602e:7faf]) by mx.google.com with ESMTPSA id b6sm14667448wiy.22.2014.11.10.12.09.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 12:09:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <546116B9.4030900@gondrom.org> Date: Mon, 10 Nov 2014 10:09:39 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <640712A4-08A9-4723-B73C-734F1F8436A2@gmail.com> References: <20141107161452.2b834f23@pc> <546116B9.4030900@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/LUYqu-iMsxYUtzFjBXrIuyaCyrs Cc: websec@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:10:06 -0000 > On Nov 10, 2014, at 9:49 AM, Tobias Gondrom = wrote: >=20 > On 10/11/14 09:03, Hodges, Jeff wrote: >> On 11/7/14, 7:14 AM, "Hanno B=C3=B6ck" wrote: >>=20 >>> But I am pretty sure that no matter what, the underlying cause needs = to >>> be fixed. >> Strongly agreed. >>=20 >>> 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. >> 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. >>=20 >> 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). >=20 > > 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=20 And DKG has mentioned not wanting to create a permanent foot-gun. That = is right, but I don=E2=80=99t think telling management =E2=80=9Cour = website is bricked forever=E2=80=9D is any better than telling them that = =E2=80=9Cour website is bricked for two years=E2=80=9D. Besides, if you move so far in the future that a 1-year or 2-year HSTS = header expires, you=E2=80=99re going to see expired certificates anyway. Yoav From asteingruebl@paypal.com Tue Nov 11 11:21:49 2014 Return-Path: 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 65A871A1AA9 for ; Tue, 11 Nov 2014 11:21:49 -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 WZkjUWCNE7P4 for ; Tue, 11 Nov 2014 11:21:48 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75591A1AE0 for ; Tue, 11 Nov 2014 11:21:47 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: 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; b=Oam4N3ETF7WDird/jOLigJR+xyCfBECk+WRYCHDZI6On3cU8fogG4D5W kg9MseN4Cb6ROwsineXAhVz9EyfYoSrEI3mFq0nlR2xxNh5mJ0qLaYKZn 1MYwZeehn8wNXO3qD1pWE/FJs7HbrTSo81i2wneO9ix0MbTus4LsAANxy U=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1415733708; x=1447269708; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s7GtkO0TqQ+MPx1Z7rsLyk38ZJj4Mel/zw1HdiU+wuk=; b=LG79ShQln9qbrilp/liTqNLiPnYFIT1M0Z7ZP/A1VqiMLtwrNMZQAF42 NKF1QsmSkM6l14I2ygzEoCrBAmJsq7AAmvOZ6jGcvEVhXFfHlomy3HErc aqPhBH9GAQS6TyRG6V1Agazju0So2tLPQsxgK74FmvTXSPHf+c2a/VAnT 0=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.07,362,1413270000"; d="scan'208";a="77048343" Received: from den-vteml-001.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 11 Nov 2014 11:21:47 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 12:21:47 -0700 From: "Steingruebl, Andy" To: Tom Ritter , Xiaoyin Liu Thread-Topic: [websec] HSTS: Infinite max-age to address NTP spoofing attack? Thread-Index: AQHP+sEJabG5KeWdAEai1Dy8HZ6SL5xWUYWAgAVxqYA= Date: Tue, 11 Nov 2014 19:21:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F6820849273C443A88F9925E683859A@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned den1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/fi_ZXVhRH4pf_igXz75dGJOBiWs X-Mailman-Approved-At: Tue, 11 Nov 2014 13:05:56 -0800 Cc: "websec@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:26:34 -0000 On 11/7/14, 4:13 PM, "Tom Ritter" wrote: >On 7 November 2014 13:28, Xiaoyin Liu wrote: >> For instance, if Twitter wants to gracefully switch to HTTP. It needs to >> send max-age=3D0 for twenty years in order to ensure that no one is lock= ed >> out. But planning ahead twenty years is impossible. So for Twitter >>switching >> from twenty years to infinity doesn't add more risks. > >With something concrete, Paypal just jumped to 2 years: >https://twitter.com/equalsJeffH/status/530840852243832833 Maybe Jeff >can weigh in on what it took to get to that confidence level and >whether he/they would rather have 'infinite'. Short story - we=B9d been running with paypal.com and www.paypal.com (but not includesubdomains) on the preloaded list in Chrome for so long that it didn=B9t seem ricky at all. The lag was really just administrative - deciding whether you need to test/re-test when you update the header since the short value was in force for Firefox, Opera, and Safari but the preloading was only enforced for Chrome. In the end we just figured we=B9d had the previous header for long enough that upping the max-age to 2 years didn=B9t seem risky. In reality I shoul= d probably have done it sooner. - Andy