Hal Murray via devel writes: > 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.
Multiplexing over a single TCP connection is how HTTP/2 works and serving multiple record and message types in the same TLS session is a fundamental TLS feature, so I'm not sure where you want to go with the non-mainline comment. I've gone and read the RFC again and it makes an explicit request for the TLS connection to be closed after one full round of the application protocol. So no, re-keying won't work with the current RFC wording. However, I also don't see the RFC getting changed substantially at this point. Anyway, the other way to skip some of the TLS overhead is TLS session resumption, which either works via session ID or sesssion ticket. The latter has some problems at least as currently implemented in openSSL, but the former could be used with relatively low effort. On the client side, repeated requests to the same NTS-KE should include the session ID from the first full TLS handshake. On the NTS-KE side you'd need to keep the session ID around for a while so that multiple connections from the same client can be recognized. From the NTS side of the protocol there is no difference and the TLS handshake is substantially shorter, so it'd probably be a good idea to start with plain multiple connects, but keep in mind that with a bit of state added to the client and NTS-KE this can later be improved. 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
