What's left to doo on NTS

[Achim Gratz]

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