Re: NTP vs. HSTS

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 
entry?

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.

..yes?

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...)

thanks,

=JeffH


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

[2] 11.2. HSTS Policy Expiration Time Considerations
     http://tools.ietf.org/html/rfc6797#section-11.2

[3] 12.3. HSTS Pre-Loaded List
     http://tools.ietf.org/html/rfc6797#section-12.3

Received on Friday, 17 October 2014 01:27:08 UTC