Re: [homenet] write up of time without clocks

[Brian E Carpenter]

On 02/11/2016 03:52, Philip Homburg wrote:
...
> 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?

That sounds absolutely dreadful for disaster recovery scenarios where
the Internet is badly broken (after a hurricane, earthquake, etc.)
and people need to restart essential systems (or they need to restart
themselves).

> 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.

No, during disaster recovery the last thing you need is for ordinary people
to be faced with strange security alerts that they've never seen before.
(It's rather like advising people to go into the BIOS to change an option
while the fire alarm is ringing.)

Things need to just work during disaster recovery.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Juliusz Chroboczek]

> But, we talked about how this wasn't a totally catch-22, that we could
> know how it was "at least" some time based upon file timestamp, or
> self-certificate not-before dates, or do DNSSEC without time validation
> first.

> My question is: did this get captured into document somewhere?

In case you decide to write something up, here's what I know about
filesystem timestamps:

  - the Raspberry Pi uses a filesystem timestamp maintained by Debian's
"fake-hwclock";
  - on OpenWRT/LEDE, something much more naive happens in 
/etc/init.d/sysfixtime.

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.

To my untrained eyes, the issue is similar to that of seeding the system
RNG for crypto purposes.  It is my impression that this particular issue
is mostly solved:

  - some SoCs have a hardware RNG (e.g. TI Sitara);
  - the ath9k WiFi driver produces system randomness from radio noise;
  - havege[1] works fine on systems that don't do it in hardware;
  - some systems save a blob of random data on shutdown, and hash it back
at startup (Debian does it in /etc/init.d/urandom).

I'll be happy to review anything you write on the subject.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet