Re: [Ntp] NTS Pools

David Venhoek <> Wed, 28 February 2024 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC34FC18DBA0 for <>; Wed, 28 Feb 2024 00:30:05 -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 bhIHqoNXU6nY for <>; Wed, 28 Feb 2024 00:30:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62e]) (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 E25C1C15152F for <>; Wed, 28 Feb 2024 00:30:00 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a3e706f50beso650075966b.0 for <>; Wed, 28 Feb 2024 00:30:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709108999; x=1709713799;; 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=y22jGAdCE+3faLdttt7pg9HT6BdW2Ug6SSNpXcWD6Xs=; b=prdp56Qk1kR7QwT62OLw1Zc8UL1qksQSxY5zHagr8gf8hLzFlZIsXNXClE8wSh20TH WrKNBZHZ5Xw3K5YbnGNwtVqGHoF4lhsXs/u/VuLME5+TxY8cFkbwcZxak1cGuXC/q+h7 rnz3Qt3HAYRhbdHLnw7RXKrXb+LNBNFVYJFkrcLVtuu6aG+/EcTDCpQfdU19fy3kHyT8 x053AHqJxb3F2B7VvVoCQrIgTOQbQdIxyRUzuQ/SF+CZiWpj73iSWTzslzZxEDs3+elN vXRVo3fTiGvdMwAWiCIO0sXJQdk7VFC66CU9B/xkEqdl5MZbTrLNvNaprGaplJO33Ld2 +qRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709108999; x=1709713799; 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=y22jGAdCE+3faLdttt7pg9HT6BdW2Ug6SSNpXcWD6Xs=; b=XrFyEUtbtRJ8Mb7D0Uvws+e+m8x1PPI2OaN6gEwO8z0+ji1LDCEXoXN/fGFp2t0Y8q ubd4pu7MK+afUdej2mMgpU1XBE42iPkawTj/8V88Nl+8/WPEEt8ChLQfeNiFRIf0bp7i bqEuLIFEBZPfODh3ZXPdxJj+7aggr1Y0VVBTXFbFSfPbdEIaQwNyshgFY5LLdyfhA1nF Hx0GdGXe4z22MGtlkDZW/50lY0MNbjYEWdMmJWsghxHfwfyFKxe+IO99KwHN0AKzU9bV SDZQ7dF/3/k5c/WhhQE5KjGTYUweK76ua1rUZwlHB2Gfat8KivL279WmlQ6D2DpH+0vZ 8Wvw==
X-Forwarded-Encrypted: i=1; AJvYcCUrN4eXf0ZgCxNKyyYSP6/PWPj6XIk4CN499hYX8cEaIxB6GNwEXECDwgRBxtwoOGZeaj/uVl6l5mb98pU=
X-Gm-Message-State: AOJu0Yx3Znd+zJNDsldOZL7mgd9O590FsVShbXypgT98zTGk9wbjwl4v IXs/y1kG3jrBIXNhGwSFKUgV8VChXpBVarMTq0ygDXuROJWUSynvenZGh720eV4etQ1+kbElw1P EE+hmcnORB29HZDkYyuZQ1XVlTQ0yq75CRjNLGL/TouL8oUL1ToU=
X-Google-Smtp-Source: AGHT+IGr35jwsHDYBtQwER78F1Ok79VpxH1zMcPd0yOmlk3VFyxqhPQKR4Z4ezO9SbNXQkOrAJNkuGKdlGPKiuyrRdM=
X-Received: by 2002:a17:906:565a:b0:a3e:6a25:2603 with SMTP id v26-20020a170906565a00b00a3e6a252603mr8629841ejr.33.1709108998825; Wed, 28 Feb 2024 00:29:58 -0800 (PST)
MIME-Version: 1.0
References: <> <Zdx0Nst2_w1mEMKG@localhost>
In-Reply-To: <Zdx0Nst2_w1mEMKG@localhost>
From: David Venhoek <>
Date: Wed, 28 Feb 2024 09:29:47 +0100
Message-ID: <>
To: Miroslav Lichvar <>
Cc:, NTP WG <>,,, Rainer Bermbach <>
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: Wed, 28 Feb 2024 08:30:05 -0000

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
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