Gary E. Miller via devel writes: >> I think you'd >> need to reconnect to the NTS-KE, but at least need to re-key the TLS >> session > > Why? To get new C2S and S2C?
Yes. >> before asking for the next server in that scenario. > > Which is the big issue. How does an NTPD client connect to an NTS-KE and > ask for a "next server"? The NTS-KE server has no state, so it has no idea > of next. The NTS-KE does have a state with the client, which is precisely the state associated with the TLS connection, which is also the base for deriving the S2C and C2S keys. > The NTPD client has no way to tell the NTS-KE server what > servers it already has cookies for. ...if the method of asking the NTS-KE a second time is to close the current and then open a new session. That's why I'm thinking it would be useful to keep the connection and just rekey it so the NTS-KE doesn't give out the same server again. > I suspect it is better for the NTPD client to as the NTS-KE server for > "X" number of NTPD servers, but the protocol has no way to do that. I think that's one of the things to figure out before the RFC goes to vote. > Next virtual meeting of the NTP WG is Feb 12. Maybe we should get some > of these issues on their agenda? Who is going to participate? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
