Hal Murray <hmur...@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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
