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

Re: NTP vs. HSTS

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Fri, 17 Oct 2014 07:41:41 -0700
Message-ID: <54412AA5.9070107@KingsMountain.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC