Re: [Ntp] Draft extension NTS for pools

[David Venhoek <[e-mail]>]

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.

On Wed, Jan 3, 2024 at 8:09 AM Miroslav Lichvar <[e-mail]> wrote:
>
> On Fri, Dec 22, 2023 at 11:27:38AM +0100, David Venhoek wrote:
> > As promised during the last interrim, a few colleagues and I have
> > worked to put into a draft the approach we have taken in our
> > experiments to get a prototype NTS pool working. The draft is at
> > https://datatracker.ietf.org/doc/draft-venhoek-nts-pool/00/, if you
>
> Have you considered a different approach, where the server instead of
> acting as a proxy simply provides a list of hostnames and NTS-KE as
> the next protocol?
>
> I think that would have some advantages:
>
> - less work for the server (>=50% of TLS sessions are offloaded to the
>   client)
> - server doesn't have to keep the TLS session open while it talks to
>   the other server, or doesn't have to prefetch and cache the data
> - keys don't have to be sent over network
> - client doesn't have to talk to the main server when it needs to
>   refresh keys/cookies
> - the selection of servers is kept on the client side
>
> --
> Miroslav Lichvar
>