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 _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
