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