NTS client configuration support has landed

[Achim Gratz]

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