Of course, we _want_ certificates to expire and be renewed. So reducing the window of vulnerability that devices with no RTCs is worth doing; using protocols that do not allow for time-based rejection of authentication information is worse than using a rough estimate of the time if we don't have an accurate clock.
On Mon, Nov 14, 2016 at 9:23 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Philip Homburg <pch-homene...@u-1.phicoh.com> wrote: > >> You write TLS, but really, I think you mean PKIX (certificates). > >> AFAIK, TLS with raw public key or PSK doesn't care about time. > >> > >> While this might be a pedantic point, I think it's important to be > >> clear about where the problem is because it reveals that there are TLS > >> uses which do not have problems, but also that the time problem is not > >> just about TLS and DNSSEC. > > > My reasoning was the following: Assume a device that has no idea about > > time when it boots. Assume that some security protocols (DNSSEC, TLS > > most of the time, etc) have as a requirement secure, somewhat accurate > > time. > > Yes, I wasn't faulting your reasoning, rather I was trying to decouple the > use of the term "TLS" from the real requirement, which is that TLS using > certificates requires time, because the certificates have expiry dates. > > I assume you saw the reference to: > https://roughtime.googlesource.com/roughtime > > > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
