In your letter dated Tue, 01 Nov 2016 13:50:43 +0100 you wrote: >Now filesystem timestamps are good enough to make sure file modtimes are >monotonic, so that tools such as e.g. make don't break; however, they >might not be good enough for crypto, since a filesystem might not be >updated for months or years (think of a device that's been kept powered >off for a year or two and suddenly needs to bootstrap its DNSSec stub >resolver). I think that designing protocols so that they can bootstrap >with time that is years in the past is absolutely necessary -- there's >just no way around it. Working around protocol deficiencies with tricks >like roughtime will lead to brittle networks.
Today, basically the only way to get reliable time is to set up a TLS connection to a trusted server that gives the device some idea about time. If the device is always on, then regularly writing timestamps to local storage is good, but only if ntp cannot step the time backwards. Assuming just plain ntp without any kind of authentication, then it doesn't make much sense to do local DNSSEC valition just to get the address of some ntp server. Note that there will be a KSK roll-over for the root zone next year. So any device that wakes up two years from now probably doesn't have valid trust material for DNS anyhow. Which brings me to the following: given that all code has security issues, maybe devices should check for updates and just shutdown if they can't verify that they are running the latest firmware? So the device should have the vendor's long term TLS certicate. With possibly an option for the user to disable this kind of security if the device is not actually connected to the internet. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
