Philip Homburg <pch-homene...@u-1.phicoh.com> wrote:
>> Which in some implementations, means having a clock to know that your
>> current firmware is actually newer than the "proposed" new firmware
>> (which is really much older), or knowing that it's been too long since
>> a firmware load.
> Where I entered the discussion is basically saying that only way to get
> secure time on today's internet that sort of scales is to start a TLS
> connection with a server you trust.
> One thing we could do is to design a secure time protocol, but I doubt
> that that is going to fly, and certainly not in the near future.
> Another thing would be to adapt security protocols to deal with less
> secure or less accurate time. But that requires actually going over
> DNSSEC and TLS and possibly other protocols and think about the effects
> of less secure or less accurate time. That can be done, but some
> working group would have too actually do the work.
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.
The google work posted earlier in the thread seems to be the protocol you
seek. But again, my goal was to write up the heuristic that explains how to
get some reasonable time *prior* to getting a default route (because the
device needs to validate certificates to get those routes).
Work items that HomeNet might consider would be "current time" TLVs for PPP(oE),
and DHCP. Could we find a way to trust them; maybe.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
