Re: [Ntp] Draft extension NTS for pools

[David Venhoek <[e-mail]>]

I'll try to add something soon about why not going for the other solutions.

For the hardware implementations, I was referring to the fpga
implementation used by netnod. While not an ASIC, fpga reprogramming
tends to be much more of a major effort than changing software.

On Mon, Jan 15, 2024 at 12:50 PM Miroslav Lichvar <[e-mail]> wrote:
>
> On Fri, Jan 12, 2024 at 09:11:32AM +0100, David Venhoek wrote:
> > 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.
>
> Ok, makes sense. It would help to explain it in the draft, why the
> more obvious solutions were not chosen.
>
> > 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.
>
> Oh, there is already an ASIC implementation of NTS?
>
> > 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.
>
> The pool can always provide its own cookies and NTP server, so I'm not
> sure if this really makes a difference.
>
> --
> Miroslav Lichvar
>