Re: [Ntp] Getting started using NTS -- clock accuracy vs certificates

[Marcus Dansarie <[e-mail]>]

On 2022-07-29 20:11, Hal Murray wrote:
> What happens if the system sits on the shelf for a month?  The system will try
> to verify certificate chains with a clock that is a month out of date.
> 
> Do certificate geeks consider that case?  When they setup a new certificate,
> do they back-date the starting time or just use "now"?  If not, then the max
> clock error is the time since the certificate was issued.
> 
> Has this issue come up in other contexts?

Since no one has mentioned it yet, I'll jump in here to say that Section 
8.5 of RFC 8915 suggests some solutions to this chicken and egg problem. 
However, if the time on the shelf is long enough, the suggestions there 
will not help since the root certificates in its store will have expired.

In the general case, I think there are two ways to handle this:

1. Trust on first use:
* Download current root certificates via HTTPS without checking 
certificates.
* Acquire time via multiple NTP/NTS servers.
* Go back and check that the HTTPS and NTS certificate chains and DNSSEC 
signatures are consistent with the acquired time and root certificates.
* Perform full time and certificate chain checks on subsequent boots.

This is vulnerable to a MITM attacks on the first boot.

2. If the vulnerability in 1 is not acceptable, have a human set time 
and provide update root certificates on first boot. Alternately, use a 
stored symmetric key to verify initial time (though this would make NTS 
redundant).

Roughtime, where servers are expected to have persistent long-term 
certificates, makes an attempt at fixing this problem. The hope there is 
that with a long enough list of Roughtime servers, the probability that 
at least one of them will still be available and using the same 
certificate should be high enough.

Kind regards,
Marcus