On 1/7/2026 8:15 PM, Hal Murray wrote:
[I'm answering your questions, not commenting on the text in the draft.]
I think this needs some clarification. Because, AFAIK NTP and NTS does
not require the client to have prior knowledge of the time either, right?
NTP works fine without any prior knowledge of time. It is not secure.
Is that true?
What's wrong with private key authentication?
NTS uses TLS. TLS uses certificates. Certificates have not-before and
not-after times.
But one can only rely on not-{before,after} if one knows what time it is.
NTS as currently deployed piggybacks on the web certificate
infrastructure. Standard software update procedres keep the root
certificates up to date.
Are you suggesting that a bad actor could not provide any attack vectors
here?
Certificates from Lets Encrypt have 90 day lifetimes. I think you get a
year or two if you pay for certificates. I've heard that there is work to
reduce lifetimes. I'm not familiar with the details. I think the idea is
to automate updating certificates so updating one is not a hassle, then we
can phase in shorter lifetimes which will reduce the damage if a private
key gets compromised.
My nasty case for getting time without any prior knowledge of time is a
spare gizmo that has been sitting on the shelf for a dozen years.
NTS could get started without knowing time if we use self signed certificates
with a long lifetime. But then we have to distribute their public keys. (as
well as run long lifetime servers.)
How do you *know* that the remote server is offering good time in this case?
Roughtime has long lifetime keys. If it gets packaged cleanly, people using
NTS won't have to worry about getting started without knowing the time and
people running NTS servers won't have to worry about self signed certificates.
Note that in addition to long lifetime keys/certificates, you also need long
lifetime IP Addresses. DNSSEC needs time.
Trustable DNS relies on reasonably accurate time.
---------
Why does the protocol only allow to obtain a rough idea of the current
time, instead of a more precise time?
Because good time isn't needed and if you don't promise good time you don't
have to spend any effort discussing how good it is or trying to make it better.
As presented, what is the significant difference between "rough" and
"more precise" time that makes a difference around whether or not a
certificate's not-{before,after} time cam be relied on?
---------
It does provide proof that the response was issued after the server
received the request, but AFAIU it does not provide any proof regarding
when the timestamp was issued.
The timestamp came from the server. You have to trust the server.
(If not, why are you using it?)
How do you know a bad actor isn't spoofing the trustable server?
--
Harlan Stenn <[email protected]>
NTP Project Lead. The NTP Project is part of
https://www.nwtime.org/ - be a member!
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
