NTS next steps

[Eric S. Raymond]

We have a number of tasks ahead of us, and I'm hoping for volunteers
to step up. I can't do all the code myself; I expect to have plenty on
my plate documenting things, being everybody's utility coder for the
interfaces between NTS and the rest of NTPsec, and reviewing code.

The tasks:

1. Prepare a note for the NTS WG on unresolved issues and
   underspecified things in the NTS draft. This needs to happen
   quickly, as the next WG meeting is on Feb 12, and the window for
   changes may not be open much longer.  I will do this and run it by
   Daniel.

2. Put together client-side NTS support.  This mainly means filling in
   ntpd/nts.c, as I have already written required the hooks into the
   protocol machine.

Any of our devs could do this, but it looks to me like James Browning
and Hal Murray have been tooling up to take on the job.  They've both
written code, James some library functions and Hal some socket-fu.

If one of you wants to lead, say so.  I will be at your service if you
need more config knobs or hooks into the rest of ntpd.  If you don't
want it, also please say so, so another volunteer can step up.

3. It doesn't make any sense for us to build an NTS-KE server of our
   own before we've tested our client side's interop with the existing
   ones - Daniel's Python implementation and/or Martin Langer's C++ one.
   Therefore one of the tasks will be to study these implementations
   and run test instances we can verify the client side against.
   Gary or Ian seem like they might be fit for that job.

We should probably start with Martin'sm as Daniel has mentioned his
Python is not conformant to the current draft.

Note that Martin Langer wrote this to me:

>Furthermore I have 3 public NTS server and I'm able to create
>special test cases for you if you need it. The first server
>(http://nts1-e.ostfalia.de/) uses an older draft version (nts4ntp-11)
>and will be updated very soon. It contains a web server too, so you
>have access to log files
>(http://nts1-e.ostfalia.de/homePi/SERVER/Logs/), certificates,
>binaries and private keys (yes, I know. Its for tests :D). Feel free
>to do what ever you want.  It's a Raspberry Pi :D

So it might well be the best way to handle this is to work with Martin.
Whoever takes lead on this should work out the details.

4. Once we've verified the client-side code, *then* it's time to build
   our own NTS-KE service.  A few hours ago Hal suggested implementing
   it as a service thread in ntpd.  The more I think about this idea,
   the better I like it - it would simplify deployment, ease
   communication with the NTP side, and make it natural to put NTS-KE
   configuration in ntp.conf.

Those of you I've mentioned, please indicate whether you can take on
one of these tasks.  Anybody else is also welcome to step in.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
	-- Chief Justice John Marshall, 1819.