I’ve just been having this idea stuck in my head for a while now, so I decided to share.
I figure, for the pool to support NTS, all the servers need a certificate that is valid for *.pool.ntp.org, which could be subject to abuse if valid certificates are handed out like candy.
So here’s my idea: The pool could have its own root certificate, which is not trusted by the OS, and starting out, the clients wanting to use NTS with the pool would have to be manually configured to trust it. I figure the pool is famous and widely used enough for vendors to take note, and may eventually start bundling their clients pre-configured to trust these certificates.
While I can’t speak for every NTP client implementation, I’ve seen the “ntstrustedcerts” option in Chrony’s documentation, and something similar in NTPsec’s documentation, that can be pointed to a file or directory containing certificates of trusted certificate authorities. Unfortunately, this does override the OS trust store for NTPsec.
Since these certificates would only be trusted by NTP clients that are configured to trust them, the potential for these certificates to be abused would be limited. The web browser would not trust it, nor would email servers/clients etc. so it can only be used for the intended use case, namely, NTS.
Then there’s also the matter of assigning these certificates to the pool operators.
ACME doesn’t seem like an ideal solution for this, since that either requires DNS verification (obviously, not happening), or web root verification (it hitting the right server would be like winning the lottery). I don’t know what a good system for assigning certificates would be.
Silly idea, or am I onto something?