Re: [Ntp] Draft extension NTS for pools

[David Venhoek <[e-mail]>]

We chose not to go that route for two reasons:

1) it wouldn't actually be enough to just exchange server keys and
standardize that. This would mean standardizing the format and
cryptographic algorithms used in encoding the cookies for the ntp
client as well. That is significantly more involved both in actually
implementing the changes, as well as standardizing it. This would
involve significantly more opinionated choices than the current
proposal. In particular, it would remove a lot, if not all, of the
cryptographic agility the suggestion we made has. Furthermore, given
the fact that hardware implementations already exist for the cookie
parsing and that these tend to be much harder to change on this point,
this would effectively lock out those implementations.

2) Although subtle, and in some cases of debatable value, there is a
minor gain in security with the current setup, in that the pool cannot
decode any of the cookies used by the individual pool servers. This
has a primary benefit when a server is both in the pool and offered
separately, as there is no need to keep two sets of keys in that
situation, giving significant extra security for direct users of that
server essentially by default. But even for pool servers it becomes
somewhat harder for the pool to attack traffic from individual pool
users as it cannot use the cookie to determine the key to use once it
has missed the first 8 polls.

On Thu, Jan 11, 2024 at 12:56 PM Miroslav Lichvar <[e-mail]> wrote:
>
> 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
>