> On Nov 10, 2014, at 9:49 AM, Tobias Gondrom <[email protected]> > wrote: > > On 10/11/14 09:03, Hodges, Jeff wrote: >> On 11/7/14, 7:14 AM, "Hanno Böck" <[email protected]> wrote: >> >>> But I am pretty sure that no matter what, the underlying cause needs to >>> be fixed. >> Strongly agreed. >> >>> A reliable time plays a role in a number of cases in TLS. >>> HPKP is basically vulnerable to the same kind of attack. Certificate >>> validity times/expirations are vulnerable. >> Yes, there's a plethora of protocols that contain timestampes of one sort >> or another. Thus to some degree or another, they rely upo systems' time, >> and if that time is corrupted by an attacker then the system and its users >> may be in trouble. >> >> I don't think it's feasible, or in all or most cases a good design, to go >> back and 'patch' those protocols to try to guard against NTP-based attacks >> (as one example of how system time may be corrupted), rather, platforms >> should (as AGL noted in a earlier thread "NTP vs. HSTS" on [1]) "fix the >> clock" (I.e. Address NTP and other clock vulns). > > <wg chair hat= off> > I agree with Jeff. It would better to aim fixing the clock issue (or the > relying on fake clocks), than trying to give "infinite" to all kinds of > protocol parameters. > Tobias
+1 And DKG has mentioned not wanting to create a permanent foot-gun. That is right, but I don’t think telling management “our website is bricked forever” is any better than telling them that “our website is bricked for two years”. Besides, if you move so far in the future that a 1-year or 2-year HSTS header expires, you’re going to see expired certificates anyway. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
