The key-manahement argument

[Achim Gratz]

Richard Laager via devel writes:
>>> * Is NTPsec going to initiate NTS by default? 
>
>> Probably not.  That would break backward compatibility.

The draft RFC states that falling back to plain NTP from NTS is not
allowed without explicit user interaction.  So choice of NTS vs. plain
NTP has to be a configuration option and cannot be made at runtime.  I
expect that NTS-KE will have easily recognizable names and/or DNS
auxiliary records that advertise them as such.

> server/pool get two new configuration options: nts and nonts. This means
> there are three possible configuration states for a server/pool:
>
> nts - Require NTS. If any part of NTS negotiation fails, do not speak
> NTP to this association. Certificates are fully validated on the TLS for
> NTS-KE (i.e. they must match the hostname, be valid time-wise, etc.).
>
> nonts - Do not attempt NTS. Behave as a pre-NTS NTP client always has.
>
> neither is set:
>
> For a pool, behave as "nonts" (because the common pool case is a public
> pool with volunteer servers that will not be able to present a valid
> certificate for the pool).

No, the RFC is pretty clear in that the NTS-KE can give out associations
for multiple NTS servers (4.1.7), which was likely introduced to support
pool-like arrangements.  Likewise the client can ask for a specific
association from an NTS-KE if it already knows one in advance.  No
certificate for the eventual endpoint is required, the validity of the
NTS-KE TLS certificate plus the fact that the NTS server knows the
correct keys tells you that you've got the right one.

The latter point means that the config for NTS-enabled associations
should allow to specify both the NTS-KE and the NTS server (the latter
is optional).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves