Re: [Ntp] Roughtime: Protocol mechanism for root key rotation?

[chris - <[e-mail]>]

Hal,


As I understand things, there are 2 uses for Roughtime.  One is
> establishing
> proof that a server is giving bogus time.  The other is getting time when
> you
> don't yet know the time.
>

Admittedly I wasn't around for the adoption call, so I'm not familiar with
all of the use cases that were discussed. But if I may, I'd like to suggest
a refinement to the first use case you mention. It's not merely about
detecting misbehaving servers; it's about getting a rough measurement of
time even when some fraction of the servers are misbehaving. Indeed, a
healthy Roughtime ecosystem (i.e., one with many independently operated
servers, see
https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md) can
provide this even if a server is simply misconfigured or not available. I
like to think of Roughtime as "rough consensus", but for time :)

Also, to add a third class of applications: Roughtime is popping up in some
web3 contexts, e.g., https://github.com/opentimestamps/restamp. There is
also https://github.com/u-root/u-bmc, which uses a server list.


If you are going to rotate a key, and you want to use Roughtime to get the
> time when you don't know it yet, you have to discuss how long a key will
> be
> valid.
>

This gives me an idea (perhaps you have a similar idea): The root key
should also include a validity period, similar to the way the online key
does. That way if verification fails due to the client having an
out-of-date public key, the client has an explanation once it learns the
consensus time and can prune it from its list of servers.



> If I put the key into an IoT type device, put that device in a pretty box
> which goes into the supply chain, how long before it gets plugged in?  Are
> you
> going to print a use-before date on the box?
>
> But that's the easy case.  The interesting case is when the device is part
> of
> a critical infrastructure and goes on the spares shelf.  How long will it
> sit
> there?  Think decades.
>

I'm a bit biased because I mostly live in the web space, but this worries
me. It might be fine for private Roughtime deployments, but for general
purposes I don't think it's a good idea to hardcode the root public key
without a plan to rotate it. Otherwise, we would have the same opsec
requirements for the root public key as we do for root certificates in the
web PKI. Indeed, root stores are regularly rotated, as part of a root
program implemented by web browsers like Firefox and Chrome.

That said, there are probably things we can do to make updating root public
keys easier. As far as I know, at the moment Roughtime operators are just
publishing public keys on websites, such as github.com or datatracker
(draft-ietf-ntp-roughtime-08 has a list of servers) or potentially on
mailing lists (https://groups.google.com/a/chromium.org/g/proto-roughtime).
One thing we can try is standardize a ".well-known" HTTPS endpoint for
fetching a server's current public key (many IETF protocols do a similar
thing). That way clients that know the consensus time can have a chance to
update their server config list (using the web PKI as a trust anchor).



> As far as I can see, if the problem is getting the time from a cold start,
> you
> have to distribute a long lifetime key and run the servers that will
> support
> that key.  Does DNSSEC work without time?  If not, you have to run the
> server
> on a stable IP Address -- stable for the length of time the key will be
> valid.
>
> Does Roughtime offer any advantages over using NTS with a self signed
> certificate with a long lifetime?
>

Here I'll just say that Roughtime is a deployed protocol with a significant
amount of real world usage. The draft is adopted, so the goal of the NTP WG
should be to specify the best-possible version of this protocol so that we
can migrate to it as soon as possible.

Chris P.