Re: [Ntp] NTS Pools

David Venhoek <> Fri, 01 March 2024 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E195DC15155A for <>; Fri, 1 Mar 2024 01:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I6CmtrUAw46Q for <>; Fri, 1 Mar 2024 01:29:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 0E7C2C151068 for <>; Fri, 1 Mar 2024 01:29:46 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a3fb8b0b7acso273080766b.2 for <>; Fri, 01 Mar 2024 01:29:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709285385; x=1709890185;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o+F25+rEZU0fTkdmFkShwKJYFVTBxHjkq1FgUNKZRtw=; b=gIS8S175Fr4k8U6krZP/mlPuquNEPhPi7vX7XcfITRRGo8NvAMNXs0rKQAGW3siHIi Yly7q+4/ZACMF18x7AfFCPzjdr5600RRTuGdax6ZP1CbEPjTfVHsq5nmyWFapK6Jew3/ 5I9rFVKneLN9XkOavlAINo3l5+/kybZii1m2UcqbaniKrq9r+9dOSrw4LwStnt6+83w3 3Nwk/NqqqaJTVOhDEpvx3wUDF7gHV6T6Ov9jG6XuKIpZY3PPj4lw7jZU163CnKQoISss 2u7sJwefiyWdjYbtctry4dIU9ZhUhEtFE6J6C2IHUHX3Tsi0KtP5jEP3G47Y27oI97j7 Q4mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709285385; x=1709890185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o+F25+rEZU0fTkdmFkShwKJYFVTBxHjkq1FgUNKZRtw=; b=rk8UdH5pCOXrzv3btMmwiBEnCPTz1UVi/cxI5fYWje39LNNGDDM7TsYU4cq4g+olBL 8OWWKvlqh6WHqqklWxMRxbe337DgoGlPqmG8U1nTkF33TjTK+IC32SMKN2G6DSkiwSqu dazmmfHuydb8CeYs0xNjL6CYOZGLP0z4cJAbg3ccVcFNKGxsL0hcM3Rv0J97QXvyyET+ SlIwwxe6fWOuqva8uTFeXgSIuAsgOoPoNLO0TOgD134/hbyekCFDRWPpo4wI9bQiFNWx GIQuc2niciAtKev+hcJiQihvyfF9YcOuifvA0SAPkYg8JkPJh/BswMwnijzEKXwB5Gqx nE7A==
X-Gm-Message-State: AOJu0Yw1B4vMrbzYvS+ewPOVnivLZBre8+itvn0xHXqgQ8GyboRAzRWp 3Dq7Std5XA8o/QSrnONKgB4Fx4EoRCj9boyTQtXzY6NkxE8Ff1wuXRphdPucIWf3B2Krjxa9g7p KYjFLt67rccKZ20OEhyj5eNkVYr1fsFbcKdT/WA==
X-Google-Smtp-Source: AGHT+IHzplkHnmN8R5QD0XklMQ0nRiQCjEVRY5kWgE6SvjZrDxoqbGudV2eN6dZFh5IDJlDQnPmSamwwM/XQMKskPsQ=
X-Received: by 2002:a17:906:ecb0:b0:a44:4678:532c with SMTP id qh16-20020a170906ecb000b00a444678532cmr887294ejb.8.1709285385047; Fri, 01 Mar 2024 01:29:45 -0800 (PST)
MIME-Version: 1.0
References: <> <Zdx0Nst2_w1mEMKG@localhost> <> <>
In-Reply-To: <>
From: David Venhoek <>
Date: Fri, 01 Mar 2024 10:29:34 +0100
Message-ID: <>
Cc: NTP WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTS Pools
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Mar 2024 09:29:51 -0000

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 <> 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:
> __________________________________________
> -----"ntp" <> schrieb: -----
> An: "Miroslav Lichvar" <>
> Von: "David Venhoek" <>
> Gesendet von: "ntp" <>
> Datum: 28.02.2024 09:30
> Kopie:, "NTP WG" <>,,, "Rainer Bermbach" <>
> Betreff: Re: [Ntp] NTS Pools
> Hi All,
> I have made a spreadsheet showing a short overview of the implications
> of the various options, see
> 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 <> wrote:
> >
> > On Thu, Feb 22, 2024 at 03:39:40PM +0100, 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 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, 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