Daniel Franke via devel writes: > The intended design for running NTS with pool servers is that only the > pool operator runs an NTS-KE server. The NTS-KE server then picks an > NTS-enabled NTP server out of the pool and serves you an appropriate > NTPv4 Server Negotiation Record. Individual server operators, on a > one-time basis, establish a shared secret with the pool operator > out-of-band; this secret is used as the master key for creating and > decrypting cookies.
I think that's a sub-optimal implementation and should be replaced by an architecture where the server operator has a certificate for their machine(s) and the shared secret is established via TLS. That would also mimic the NTS-KE to client communication more closely and would perhaps allow to share some code. It would also allow to limit the amount of time an NTS-KE tries to serve clients with a server address that's not responding if a TLS session resumption would be required at some minimum interval. > As recommended in the draft RFC, this key can be > rotated on a periodic basis using a key-derivation function such as > HKDF as a ratchet. Since new keys are deterministically derived from > old ones (using a one-way function so you can't go backward), no > communication is required as long as the pool operator and server > operator agree on a schedule for generating new keys and forgetting > old ones. They don't have to synchronize this perfectly; as long as > the pool operator isn't still issuing new cookies under a given key-ID > when the server operator has already forgotten that ID, it'll work. IIUC, that gives you a long time window to try and crack any key and then wind things forward to where you have the current one. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
