What's left to doo on NTS
Hal Murray
hmurray at megapathdsl.net
Mon Mar 4 10:05:43 UTC 2019
Eric said:
> Trying to change that by breaking out a separate NTS-KE server would
> introduce a lot of complexity when we could achieve the same result by
> pointing the ntpd instances at a common key on a fileshare.
That adds the fileshare to the security tangle and probably complicates the
startup dance.
> If you don't trust that your LAN is secured enough to do that, you can't
> trust it enough to pass NTS-KE traffic over it either.
Huh? The NTS-KE traffic in encrypted by TLS.
-------
> I now think this plan is a mistake and that Hal did the right thing by
> building key service into ntpd itself.
I could see all the pieces and how they fit together. (and I didn't have to
write the code to read K/I from the disk to get started).
The server side of NTS-KE is not very complicated. A stand alone server would
be simple.
173 553 4497 ntpd/nts.c
494 1561 14317 ntpd/nts_client.c
242 783 5713 ntpd/nts_cookie.c
238 761 5610 ntpd/nts_cookie.cc
415 1295 11866 ntpd/nts_extens.c
414 1247 11905 ntpd/nts_server.c
1976 6200 53908 total
The client and extens are not needed for a NTS-KE server.
It is not tightly tangled with ntpd. It needs msyslog and a bit of
initialization. The hard part would be coordinating K/I with the ntp servers.
--
These are my opinions. I hate spam.
More information about the devel
mailing list