ntp.conf changes for NTS
Achim Gratz
Stromeko at nexgo.de
Sat Feb 2 07:26:26 UTC 2019
Gary E. Miller via devel writes:
>> Both keys should only ever be used by a single client/server pair.
>
> Yeah, but no way to enforce that. A black-, white-, or gray-hat could
> easily reuse the same keys on thousands of servers at the same time.
There is a virtual guarantee of unique keys if each client/server
pairing goes through its own TLS handshake.
> You easily get up to millions of known plaintext/known ciphertext pairs,
> the nonces become overwhelmed and the master key recovered.
Sorry, this is plain nonsense. You will not create enough messages for
this to ever be a problem even on a terabit link. And the RFC already
asks you to do a key rollover on a ~day timescale, so you have even less
chance to produce so many messages.
> By definition there is no trust in the pool.
Then you must not share keys.
> OK, re-keyed, but I see nothing in the Proposed RFC to support this mode
> of operation. Sure, TLS alone supports re-keying, but the NTPD client
> has no way to request a 2nd, different, NTPD server and cookie.
Again, that happens at the level of the TLS session, the RFC operates
inside that session. I'd prefer if that was described in the RFC, but
you can do it as an implementation defined thing outside of its scope.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
More information about the devel
mailing list