Proper cn in certificate for use with NTS

I’m tinkering with NTS on and – NTS seems to be working, but which cn (in the x.509 Certificate) should pool servers use?

Turns out that both servers can properly communicate using and

server nts iburst
server nts iburst

I would assume you would put the proper hostname of your machine, whatever a reverse lookup of your IP resolves to? NTPSec is the only program I know of at the moment that has implemented the draft NTS spec, and unfortunately I haven’t had time to mess around with it…

If you have to implement all the various continent/country pool aliases that could be extremely tedious…

The NTP Pool does not officially support NTS (or any authentication scheme) at this time…

The current NTS spec doesn’t support use cases like the pool, sadly.

There’s been some discussion in the working group about it, but nothing made it into the draft.

(It’s sad to me because outside the OS vendor NTP services I believe we service a huge part of the NTP queries done in the world, so even if “security” has different trade-offs for a public volunteer run service like ours, it could still have value).

Yes, I thought it would be “nice to have”, but I see the issue with additional CN values (SubjectAlternativeName) and the like.

What exactly is missing in NTS to be usable in Do we need the servers to be in multiple zones? Would a wildcard certificate not work?

For a start, I thought there could be a single experimental (e.g. zone, which would resolve to servers that support NTS. The pool system would generate a different certificate for each server, which would be valid for a short period of time (e.g. one week) and would have to be periodically updated. To make it a little bit more difficult for attackers, only servers that have at least one year of good history can be in the nts pool.

Is that not worth the trouble?

1 Like

I don’t think it’s worth the trouble, especially until NTS is finalized and implemented in more NTP packages / products.