W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: NTP vs. HSTS

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Thu, 16 Oct 2014 18:26:36 -0700
Message-ID: <5440704C.50505@KingsMountain.com>
To: W3C Web App Security WG <public-webappsec@w3.org>
Adam Langley <agl@google.com> wrote:
 > we do have a timeout
 > for HSTS preloads which git blame says that I added, although I don't
 > remember it. The timeout is the same as our pinning timeout, which is
 > 10 weeks from the build timestamp.

I'm curious what the rationale is for such a timeout on an HSTS pre-loaded 

I note that with HPKP, there seems to be such rationale, expressed in S4.1. 
  Maximum max-age [1]..

                  ... There is a security trade-off in that low maximum
    values provide a narrow window of protection for users who visit the
    Known Pinned Host only infrequently, while high maximum values might
    potentially result in a UA's inability to successfully perform Pin
    Validation for a Known Pinned Host if the UA's noted Pins and the
    host's true Pins diverge.


It seems similar rationale could ostensibly be applicable to HSTS Hosts also 
-- in that if for some reason they wish to begin offering an unsecured HTTP 
endpoint that's been "covered" by HSTS policy (eg via includeSubdomains), 
and so if they are in the pre-loaded list, and that never ages-out, then 
they're stuck. (it appears that RFC6797 doesn't discuss this particular case 
in either [2] or [3])

Does the HSTS preload entry timeout occur only if the UA hasn't noted an 
HSTS policy emitted from that HSTS host prior to the timeout expiry? (do you 
have a pointer to the code, I'm curious...)



[1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-4.1

[2] 11.2. HSTS Policy Expiration Time Considerations

[3] 12.3. HSTS Pre-Loaded List
Received on Friday, 17 October 2014 01:27:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC