NTS: What next?
hmurray at megapathdsl.net
Thu Apr 11 09:31:38 UTC 2019
I'm close to finishing cleaning up all the FIXMEs I had left behind.
There are 2 major items on my list:
More and/or alternate certificate checking.
There are lots of possibilities in this area. I haven't found one that
looks clean and simple. We can afford modest amounts of setup work since we
know the target servers and they don't change often. (as compared to a web
client where you may see a new server on each mouse click, and the user wants
it right-now) We also have to consider getting started without knowing the
time. Eric: Have you looked at this area?
I carefully said "cluster" rather than "pool". I'm interested in the case
where all the NTP servers are run by the same organization or at least the
server operators are well known and trusted by the cluster admin.
I think the current code is ready for a release and more testers. We can't do
a "Supports NTS" release until the draft turns into a RFC since some numbers
haven't been assigned by IANA yet. Call it pre-beta or some good weasel-word
The current code has one interesting quirk. The cookie key gets rotated every
hour rather than every day. If your polling interval ramps up enough, your
cookies become invalid and that tests the retry NTS-KE logic. We will want to
remove that before a non-beta release. Maybe sooner.
There is a potential item: We may need the NTP server to listen on some port
in addition to 123 in order to get around various filtering rules leftover
from NTP DDoS amplification attacks. Need more data which a release would
Medium size items:
I think we need a couple of scripts for monitoring certificates. Details
TBD, but I'm thinking of things like when does my certificate expire and tell
me ??? about the certificates on the servers I'm using. This will get more
interesting when we figure out what to do about additional certificate
checking. It would be half just a convenient reminder of how to do things and
maybe a cron job to warn you that your certificates are timing out or some
server's certs are busted.
Save a couple of cookies to disk so we can restart/reboot without going
through NTS-KE. They need to be refreshed occasionally. That also means
saving S2C and C2S. Maybe we should go through the NTS-KE exchange
occasionally to refresh S2C and C2S.
We need a good writeup on getting started when the system time may not be
known. That means we have to understand the issues.
We need to think about statistics. This is more than a NTS issue. Currently,
"ntpq -c nts" does what I want, but nothing gets logged to disk. Other
log-to-disk chunks clear the counters that ntpq shows. Sometimes, I want to
see the totals. Mumble. Maybe we should save the totals and have ntpq show 2
columns: totals and recent. Or maybe a mode where it divides the columns by
How is the documentation?
I thought there was work on a HOWTO level doc, but I can't find it.
I want to make 2 programs, a client and server for NTS-KE. Stand alone.
Simple. Partly as an example of how to use OpenSSL, what I was looking for
when I was getting started, and partly for debugging NTS-KE, just lots of
printout to show what the other end is doing. (Eric: This might be an
interesting go exercise.)
Next is a NTP client using a cookie saved from above. I want to hack this to
be able to measure server performance. Shared key too.
These are my opinions. I hate spam.
More information about the devel