What's left to doo on NTS

[Achim Gratz]

Hal Murray via devel writes:
>>> 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.

Security never is an all-or-nothing thing, but if you want to view it
that way we can agree to disagree.

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

Again, you talked to an NTS-KE that you verified as being the pool
NTS-KE and you can be sure that the NTS you're talking to is the one the
NTS-KE gave you the cookies for.  Compare with the current state of
taking whatever DNS response you've got (not secured in any way) and
talking to whatever happens to be at the other end.

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

Load sharing is not the objective, resiliency of the infrastructure is.

> 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.

No, you'd simply use a TLS session between the NTS-KE and each NTS and
use the in-session key-derivation functions.  That could be an almost
copy of the NTS-KE to client communication.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables