> 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.
Good sugestions, thanks, but it's all an implementation of get a batch of answers from one NTS-KE server. I think it would be simpler to fix the NTS-KE protocol and probably a good idea to stay away from non-mainline uses of TLS. I think we should put pool stuff on the back burner. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
