Re: [Ntp] Draft extension NTS for pools

[Miroslav Lichvar <[e-mail]>]

On Wed, Jan 10, 2024 at 12:26:18PM +0100, David Venhoek wrote:
> We have thought about similar approaches (in particular the suggestion
> from Christer Weinigel at the hackaton in London to do this with dns
> SRV records), but we in particular decided very early on to focus on
> an approach which doesn't require any modifications to the client.
> 
> We made this decision because we feel that this drop-in compatibility
> is one of the key factors also behind the success of the original ntp
> pool. Requiring modifications to clients would slow adoption and will
> likely result in clients (at least in the short and medium term) that,
> although they do support nts, will not work together with such a pool.

I don't see advantages of this approach over what is already possible.

If you are willing to modify the servers (but not clients), why do all
this complicated proxying when the server accessible under the pool
name could be running full NTS-KE itself and generating keys (e.g.
once per week) for the other servers running only NTS-NTP?

The TLS load of the NTS-KE server would be halved as it doesn't
have to connect to other servers as a client. The keys don't have to
be shared among the NTS-NTP servers (potentially running by different
people). The NTS-KE server can select the keys according to the NTP
server negotiation record.

If the goal is to interoperate between different NTS-NTP/NTS-KE
implementations, we can specify a protocol or file format for
exchanging the server keys and their validity period.

-- 
Miroslav Lichvar