Subject: Re: [Ntp] Splitting the Roughtime draft?

From: Hal Murray <[email-masked]>
Date: Sun, 31 Jan 2021 01:06:07 -0800

[email-masked] said:
> I think we need to be very clear about the fact that all trust in Roughtime
> is rooted in the long-term keys and that they are expected to be valid for a
> very long time indeed. 

How long is "very long"?

I've been trying to figure out how to use Roughtime to get NTS off the ground 
when the time isn't known/trusted yet.  If it needs long term keys, is there 
any advantage to long-term Roughtime keys as compared to trusted certificates 
with a long lifetime?

-- 
These are my opinions.  I hate spam.

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 31 Jan 2021 10:14:20 +0100

>> is rooted in the long-term keys and that they are expected to be valid for a

There is currently no way of specifying the end of validity for the
long-term keys. My interpretation of that is "until the key is impeached
or revoked". Ideally, I should be able to configure a client with a
number of Roughtime servers and turn if off for a decade. When I turn it
on again, it should hopefully receive valid time from at least a handful
of servers.

> any advantage to long-term Roughtime keys as compared to trusted certificates 

Not really. The major difference is that the Roughtime keys don't have
an end date and no CA that acts as a trust anchor.

Kind regards,
Marcus

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Jan 2021 13:07:08 -0800

> > is rooted in the long-term keys and that they are expected to be valid for a

CT logs are active for one year of certificate expiry, but that's due
to log growth causing issues. Roughtime keys could be used for
multiple years, although shorter lifetimes would force updates on
clients. I'm open to suggestions.

> any advantage to long-term Roughtime keys as compared to trusted certificates

You shouldn't bake in ecosystem.json and expect this to work securely.
The benefit of roughtime is that malfeasance is detected, hence
updates can remove bad servers without much trouble, and it readily
provides enough accuracy for X509 validation. Set and forget with a
limited number of servers doesn't enable those ecosystem benefits.

What we observe in the browser world is that even 24 hour windows of
validity are problematic for clients due to inaccuracy, but a few
seconds of accuracy is just fine for X509 validation.

Sincerely,
Watson Ladd

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

--
Astra mortemque praestare gradatim

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 01 Feb 2021 08:29:03 +0100

>>> Hal Murray <[email-masked]> schrieb am 31.01.2021 um 10:06 in
Nachricht <[email-masked]>:

>> is rooted in the long‑term keys and that they are expected to be valid for
a
> How long is "very long"?

The "industry standard" seems to be 10 years for that, while "long" nowadays
is probably only two years...

> 
> any advantage to long‑term Roughtime keys as compared to trusted
certificates 
> ‑‑