- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Fri, 17 Oct 2014 07:41:41 -0700
- To: Adam Langley <agl@google.com>
- CC: W3C Web App Security WG <public-webappsec@w3.org>
Adam Langley <agl@google.com> wrote: > On Thu, Oct 16, 2014 at 6:26 PM, =JeffH <Jeff.Hodges@kingsmountain.com> > wrote: >> 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...) > > If dynamic state applies then the fact that the static HSTS entries > have timed out is immaterial: ok, good. > https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state.cc&sq=package:chromium&rcl=1413420779&l=110 thx. > The timeout was so that entries could be removed from the list, yes. ok. > I could change that but lots of things go wrong if the clock is wrong. indeed. considerations of that factor -- bad clock -- is missing in the HSTS spec. > A > better answer is to fix the clock yes, there's certainly cascading issues from NTP & system clocks that ought to be addressed. although, there'll always be the chance a system's clock is "off" relative to other entities. thus we need to acknowledge that in specs & implementations that have dependencies on time & clock(s) (and I/we missed addressing that in HSTS rfc6797 (i'll submit an errata)) > it would be very nice if OSes would do that. yep. thanks, =JeffH
Received on Friday, 17 October 2014 14:42:19 UTC