Re: [Ntp] NTS Pools

[David Venhoek <[e-mail]>]

Building upon the previous email, let me also clarify what my aims
were/are with the draft published a few weeks back.

Goal:
My primary goal currently is to work towards a pool or pool-like solution that
1) Is drop in for end-users. I.e. if you have a working NTS client,
the pool can be used without any changes to software.
2) Can support hetrogeneity in the time server implementation, i.e.
does not force a specific NTP implementation or set of cryptographic
primitives.

This has the primary aim of securing the connection between the client
and the time server, similar to what the aim of Let's encrypt is for
http. Such encryption is valuable on its own as it protects users from
impact from insecured wifi networks. In other words, my focus is
primarily on the first of the two forms of trust.

The rationale behind the first subpoint is that this is in my view
critical for adoption. Without it, I think it is hard to get to a
critical level of adoption. Furthermore, requiring specific support in
the client likely means there will always be some clients not
supporting that pool.

As for the second point, this is in my eyes important as it can help
lessen the impact from security issues with any one implementation.


Rationale for the NTS-KE load balancer approach:
Given these goals, I myself find the NTS-KE load balancer approach the
most attractive. Requirement 1 limits the options to either Shared
domain name, NTS-KE generating cookies or NTS-KE load balancer.

The poor isolation between NTP providers for the Shared domain name
option makes it unattractive to me as any NTP provider could still man
in the middle, meaning that ultimate trust is needed in all of them.

An NTS-KE server generating cookies can be a good opton, particular in
more tightly controlled setups where all servers are running the same
software. However, when running multiple implementations this would
either require standardizing cookie formats (reducing cryptographic
agility for those) or implementing all the various cookie formats used
by the implementations. This latter option would involve significantly
more implementation work and potentially makes upgrades tricky should
anything ever change in the cookie format, requiring additional
coordination.

Kind regards,
David Venhoek

PS: I forgot to properly open up comments on the sheet previously.
They are now open, feel free to place comments on it.

On Wed, Feb 28, 2024 at 9:29 AM David Venhoek <[e-mail]> wrote:
>
> 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 <[e-mail]> wrote:
> >
> > On Thu, Feb 22, 2024 at 03:39:40PM +0100, martin.langer=[e-mail] 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
> >