> This started with a need for somewhat accurate system time for > certificate validation, right? I have to deal with stuff lacking > a RTC battery. I save system time every now and then in flash. > During startup, clock jumps forward to RTC when warm start occurs > (main power was not interrupted) or to saved system time when a > cold boot occurs. When clock is behind, it jumps forwards when NTP > syncs. My certificates do not expire during "powered off, on the > shelf".
The problem is that security protocols like TLS and DNSSEC rely on secure, accurate time without specifying how to get that. At the moment we don't have any way to distributee secure accurate time of a large scale. Without accurate time you have too fool around to make it work. And without a serious security analysis, you will only find out what it means to rely on a best effort time service when the security of your system is broken (or a security researcher gives a nice presentation on a security conference). Note that just saving the time to flahs is very likely to break DNSSEC. Many zones have very short lifetimes (in the order of weeks). So if the device is off for a couple of weeks, the local time will be before the start time of the signature and DNSSEC validation will fail. My guess is that as letsencrypt is becoming more wide spread, having a clock off by a couple of months will also cause issues there. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
