Re: [Ntp] NTS Pools

Dear Martin,

I believe that this was sufficiently explored in the original design
of NTS, and is sufficiently solid to proceed with practical
implementation and experimentation. Furthermore, I think we should not
let perfection stand in the way of improvement in this particular
case. The NTP pool right now is very popular precisely because it is
very very easy to use for end users. Having something similar but
using NTS does not solve all attack vectors posed by a pool, similar
to how HTTPS doesn't solve all website security issues on the
internet. However, it does remove a class of attacks and is worth it
for that in my view.

As for the current pool, it works through the DNS resolution
dynamically providing A records depending on the location of the user
and the current state of the pool.

Kind regards,
David Venhoek

On Thu, Feb 29, 2024 at 1:59 PM <martin.langer@ptb.de> wrote:
>
> Hello David,
>
> thank you for this. It is very helpful.
>
> Before developing and implementing a solution, we should first identify the potential threats.
> An NTS/NTP pool makes the security assessment more difficult because we provide more attack vectors.
> In addition, the question of an "initial" time to verify certificates becomes even more important.
>
> Do you happen to know how NTP pools are queried? Is it done over the HTTP protocol?
>
> Best regards,
> Martin
>
> __________________________________________
> Dr.-Ing. Martin Langer
> Physikalisch-Technische Bundesanstalt (PTB)
> Working Group 4.42 "Dissemination of Time"
> Bundesallee 100,
> 38116 Braunschweig (Germany)
> Tel.: +49 531 592-4470
> E-Mail: martin.langer@ptb.de
> __________________________________________
>
> -----"ntp" <ntp-bounces@ietf.org> schrieb: -----
> An: "Miroslav Lichvar" <mlichvar@redhat.com>
> Von: "David Venhoek" <david@venhoek.nl>
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> Datum: 28.02.2024 09:30
> Kopie: martin.langer=40ptb.de@dmarc.ietf.org, "NTP WG" <ntp@ietf.org>, Dieter.Sibold@ptb.de, Kristof.Teichel@ptb.de, "Rainer Bermbach" <r.bermbach@ostfalia.de>
> Betreff: Re: [Ntp] NTS Pools
>
> Hi All,
>
> I have made a spreadsheet showing a short overview of the implications
> of the various options, see
> https://docs.google.com/spreadsheets/d/1rxEArrbN5OKgsFI9KUzmOzI1twDztQc6aEUZr5WelVU/edit?usp=sharing
>
> Glossary of terms:
> Pool: the actual entity operating the dns record and infrastructure of the pool
> NTP provider: entity providing time as part of the pool.
>
> The options currently included in the sheet are the following:
>
> Upgrade from IP
> ---------------
> Suggested by among others Martin
>
> Idea: Client gets IP address via DNS, if it also accepts connections
> on tcp:4460 then upgrade to NTS. The server on tcp:4460 uses a TLS
> certificate for the IP address on which it is running
>
> DNS SRV records
> ---------------
> Suggested by among others Watson, Miroslav, Christer
>
> Idea: Client gets SRV records via DNS containing FQDM of actual NTP
> provider. It then does NTS-KE with the FQDM in the srv record. The ntp
> provider has a certificate for the domain name in the SRV record.
>
> Shared domain name
> ------------------
> Not sure who originally suggested it.
>
> Idea: All NTP providers run their own NTS-KE servers under the domain
> name of the pool. All providers have TLS certificates for the pool
> domain name.
>
> NTS-KE generating cookies
> -------------------------
> Suggested by among others Miroslav
>
> Idea: Pool runs NTS-KE server which generates cookies for the various
> NTP providers.
>
> NTS-KE load balancer
> --------------------
> Suggested by among others David
>
> Idea: Pool runs NTS-KE server which contacts an NTS-KE server from the
> NTP provider and they coordinate to create cookies.
>
>
> Separately from the discussion on which infrastructure approach to
> take there has also been a discussion on the security model.
> Essentially, there are two forms of trust involved in NTS (credit
> Dieter):
> 1) Trust that I am talking to the server which I intended to talk to.
> 2) Trust that the server I am intending to talk to has the correct time.
>
> The discussion on technical approach mainly affects 1. 2 depends
> mostly on how the particular pool is operated (note that this means
> that, unlike with the NTP pool, there is thus room for more than 1
> type of public/wide area pool)
>
> Hope this clarifies the discussion for those not as intimately
> involved. If anything is missing in the sheet please suggest edits
> either here or on the sheet.
>
> Kind regards,
> David Venhoek
>
> PS: I will email separately later with an indepth reaction to the
> points raised by Martin, Dieter and Miroslav, as I am out of time for
> now. However, this should provide a reasonable overview to serve as
> the foundation of that discussion.
>
> On Mon, Feb 26, 2024 at 12:21 PM Miroslav Lichvar <mlichvar@redhat.com> wrote:
> >
> > On Thu, Feb 22, 2024 at 03:39:40PM +0100, martin.langer=40ptb.de@dmarc.ietf.org wrote:
> > >    I was talking with Krisof Teichel, Dieter Sibold and Rainer Bermbach about
> > >    how we should handle NTS secured NTP pools. It's not easy as there are
> > >    different perspectives on the purpose, use cases and security
> > >    considerations. In general, I think I can provide support from the PTB
> > >    side, even though I have very little time for it at the moment.
> >
> > I'm getting lost in these "NTS support in pools" discussions. I'd
> > appreciate if someone could clarify what exactly is meant by pool and
> > what is the intended use case in the different proposals.
> >
> > For me, a pool is a set of servers available under the same DNS name,
> > which can be specified in the client's configuration with a pool
> > directive to use some number of the servers at the same time instead
> > of a single server. There is the well-known pool pool.ntp.org with
> > thousands of servers provided by volunteers and there are other
> > smaller pools run by different companies and organizations.
> >
> > This DNS-based concept of a pool works with plain NTP and it works
> > also with NTS. There can be multiple NTS servers available under the
> > same name. The client can use more than one server at the same time.
> > The NTS-KE part can be separated from the NTS-NTP part. The client
> > doesn't care. I've been using my own mini pool of NTS servers without
> > any issues since NTS became a thing.
> >
> > There are now three different proposals to solve some issues with NTS
> > wrt pools. There is the older one from Watson based on DNSSRV records
> > and two newer ones from David and Martin. Can anyone summarize what
> > issues do they solve and don't solve?
> >
> > One idea seems to be to run one NTS-KE server with multiple NTS-NTP
> > servers and mix different implementations of NTS-KE and NTS-NTP. What
> > exactly is the use case for that? My understanding is that NTS-KE is
> > the weakest part of the whole system, most easily overloaded and it
> > the ratio should actually be inverted, run more NTS-KE servers for one
> > NTS-NTP server.
> >
> > If NTS was to be supported in the pool.ntp.org pool, I think NTS-KE
> > servers would need to be run by the volunteers, not on the
> > pool's own limited resources. I'd not expect many of them to be
> > separated from NTS-NTP and even fewer of them mixing different
> > implementations.
> >
> > If I have a limited number of computers to provide an NTS service, why
> > would I want to split them into NTS-KE and NTS-NTP servers, when they
> > can all provide both functions at the same time and provide a larger
> > capacity for NTS-KE and NTS-NTP?
> >
> > --
> > Miroslav Lichvar
> >
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp