Interesting screwup case

[Richard Laager]

On 2026-03-24 07:04, Hal Murray via devel wrote:
> I have a Raspberry Pi running Fedora.  They don't have a version of
> fake-hwclock in their collection.  So it came up with a bogus date/time.
> 
> That box was setup to use NTS on all its servers.  The certificate checks
> failed due to invalid dates.  All of them.  So the box was just sitting
> there, retrying the NTS-KE step occasionally.

> Should we add a hack to do something like set the clock to the date from
> the drift file if it is before the build date?

I still like my idea, but I don't have time to attempt an 
implementation. Here is a previous discussion:

https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html
[Note that OCSP stapling is dead these days. So ignore those bits.]

Here is a shorter summary:

0) Have a flag (command line option and/or configuration file setting) 
for bootstrapping mode. For security and backwards compatibility, it 
probably should default to off. (Maybe this should be per-peer, but 
that's probably too complicated and unnecessary.)

1) When in bootstrapping mode: If certificate validation fails, retry 
validation following the usual rules EXCEPT the notBefore/notAfter 
constraints.

Note that you cannot just ask OpenSSL to verify and then ignore failures 
based on the failure reason, because it might have bailed on first 
failure and there could be other problems. This might require ntpd to do 
certificate validation. If so, still have OpenSSL do the initial 
validation, to limit the damage that a bug in our custom validation 
logic could do.

If this succeeds, then mark the association as "suspect", and store the 
notBefore and notAfter constraints from the end certificate with that 
association.

2. When receiving time on a suspect association, the time MUST be within 
the saved notBefore and notAfter constraints. Otherwise, it is 
completely ignored no matter what. In other words, the server's time 
must line up with the certificate it(s NTS-KE server) presented.

3. When applying the usual (clustering, etc.) rules to set the time, 
initially ignore suspect associations. If you reach a consensus on the 
time, immediately clear the bootstrapping mode flag, kill all suspect 
associations, and start them over. If you do not reach a consensus, then 
keep waiting up to a certain amount of elapsed time from ntpd startup. 
After that amount of elapsed time, start considering the suspect 
associations too. Again, as soon as you reach a consensus, you end 
bootstrapping mode, kill the suspect associations (even if they were 
used to set the time), and start them over normally.


The exception is limited. It only applies to the timestamps in the 
certificate, only if necessary to achieve consensus and set the time, 
only for the initial setting of the clock, and only if enabled by the 
admin. And the time must still align with the certificate(s) presented.

-- 
Richard