NTS client configuration support has landed

[Achim Gratz]

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