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