Hal Murray via devel writes: >> You might be right, but I'm not going to design on the assumption that you >> are because the payoff matrix is too asymmetrical. > > Just because the current pool is untrustworthy doesn't mean that somebody > couldn't run a trusted pool.
No, in fact my expectation is that the ntpsec implementation should support an NTS pool. > Keep in mind that pool+nts isn't well specified yet. I agree, but it's specified well enough to work. Not well enough to work efficiently, which creates more load on the pool NTS-KE servers and some monkey work on the client side (that the current pool code also has to do, but should be gotten rid of, really). > Do we want to get the > info for several servers with one NTS-KE connection, or do we want to do the > a > DNS lookup to get several IP Addresses and then use separate NTS-KE > connections with each of those addresses? I think this discussion really needs to take into account that the NTS-KE communication happens inside a TLS session, which is a layered communication channel w/ internal state. Possible solutions can be implemented at several of these layers. Taken at face value the current RFC would imply a full TLS session teardown and reconnect. I think that you could do the same "reconnect" while keeping the TLS session open (thus avoiding all the certificate checks and cipher negotiation) and just re-key. Last but not least I _think_ it is possible to have several virtual connections inside the same TLS session (that would only work for NTS if they can at least have different IV), so that would be another route to ask for multiple servers within one TLS handshake. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
