[Ntp] Antwort: Re: NTS Pools

[[e-mail]]

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.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"ntp" <[e-mail]> schrieb: -----

An: "Miroslav Lichvar" <[e-mail]>
Von: "David Venhoek" <[e-mail]>
Gesendet von: "ntp" <[e-mail]>
Datum: 28.02.2024 09:30
Kopie: martin.langer=[e-mail], "NTP WG" <[e-mail]>, [e-mail], [e-mail], "Rainer Bermbach" <[e-mail]>
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" rel="nofollow">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
>

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp