What's left to doo on NTS

[Hal Murray]

>> There is no security in the pool anyway, so let's put that discussion
>> aside for a while.
> I'd take exception with that statement.  If the pool was upgraded to use NTS
> one way or the other, it _would_ provide some extra security over the status
> quo.  It's a different kind of security than what you get from running your
> own time servers, ...

Putting a lock on the front door when the back door is wide open doesn't 
provide security.  I expect that security geeks have a term for that similar 
to security-by-obscurity.

I don't see how to use NTS to make something like the current pool secure.

-----------

But let's consider something like the NIST servers - many but not zillions.  
What tools do we have for secure load sharing?

Plan A is to give all the servers the certificate and private key for 
time.nist.gov and do the load sharing via traditional DNS rotation.  The 
disadvantage with that is that there are many copies of the private key out 
there.  One leak and the whole system goes insecure.

Plan B gives the servers individual certificates and names.  Now we have to do 
the load sharing at the DNS level.  I'm not a DNS wizard.  NIST already uses 
CNAMEs for this.  There is no POSIX API for getting the CNAME, so we would 
have to write some DNS code or find a library we like.

Plan C is that the servers don't need any certificates.  We have a central 
NTS-KE server that returns the IP Address of the assigned server along with 
the initial cookies.  That requires coordination between the KE server and the 
NTP servers that will decode the cookies.

Plan C1 is that the ntp server and KE server keep their idea of K in sync.  
There is discussion of a way to do that in the draft, presumably for things 
like this.  The idea is that they both use the same algorithm to determine the 
next K.  I'm not a crypto geek.  I'd be happier if I didn't have to use that 
approach.

Plan C2 is that there is a secure communication path between the KE server and 
each ntp server.  A script with ssh/scp could do it.  Send the new key file, 
and send a signal to ntpd to reload K.  Or send the same info over a TLS 
connection.

Plan B and C can coexist.  Pick a nearby server by hand and use plan B.  Or 
talk to the generic KE server and it will give you IP Address and initial 
cookies.


-- 
These are my opinions.  I hate spam.