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