Going forward with NTS

Eric S. Raymond esr at thyrsus.com
Wed Feb 6 00:50:22 UTC 2019


Hal Murray <hmurray at megapathdsl.net>:
> 
> Eric:
> > I plan to post a detailed analysis and task list later today.  I'm working on
> > that now. 
> 
> I have hack code that makes a TLS connection and verifies certificates.
> 
> If/when things calm down, I'll start folding it in.

If that was going to go into nts.c for the client-side support, now
would be a good time. Whatever we write in there will need that layer.

> ntpd/ntpd.c has a main() in it.

I'm guessing you mean ntpd/ntsd.c.

> Is the plan to have NTS-KE-server packaged as a separate program?
> Why not a separate thread in ntpd?  That seems like it would be
> simpler to admin for the common case.

I think we'd best completely avoid writing an NTS-KE server until we
have tested our client side against one of the two existing server
implementations.

I had been assuming ntsd would be a separate binary, hence the stub.
But the idea of making it a thread in ntpd is kind of interesting.
It would simplify a number of things.

> There is the standard DoS attack problem on any system using TCP.
> Is there a good writeup on that we can point to?

I don't know of one, but infosec is not my area of expertise.
Perhaps someone who does know will speak up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.




More information about the devel mailing list