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. Best, Xiaoyin ________________________________ From: Daniel Kahn Gillmor<mailto:[email protected]> Sent: 11/7/2014 10:05 AM To: Xiaoyin Liu<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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? --dkg
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
