Re: [Ntp] NTS pool support

Ask Bjørn Hansen <> Mon, 22 July 2019 06:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 226FD120142 for <>; Sun, 21 Jul 2019 23:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y3qgdLUWlxsz for <>; Sun, 21 Jul 2019 23:25:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 08A2A12010D for <>; Sun, 21 Jul 2019 23:25:34 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44D906E008D for <>; Mon, 22 Jul 2019 06:25:34 +0000 (UTC)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0417C175A55 for <>; Sun, 21 Jul 2019 23:25:34 -0700 (PDT)
Received: (qmail 18249 invoked from network); 22 Jul 2019 06:25:33 -0000
Received: from (HELO ? ( by with ESMTPA; 22 Jul 2019 06:25:33 -0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= <>
In-Reply-To: <>
Date: Sun, 21 Jul 2019 23:25:19 -0700
Cc: Christer Weinigel <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Ntp] NTS pool support
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2019 06:25:37 -0000

> On Jul 21, 2019, at 0:28, Patrik Fältström <>; wrote:
> On 21 Jul 2019, at 5:18, Ask Bjørn Hansen wrote:
>>> On Jul 20, 2019, at 1:37 PM, Christer Weinigel <>; wrote:
>>> The best thing about DNS SRV records is that the target (host) is a
>>> fully qualified domain name, which means that when the NTS client
>>> connects to the NTSKE server it will match the name that's present in
>>> the TLS certificate for the server.  This means that the administrator
>>> of the pool does not have to manage the TLS certificates and private
>>> keys, that's up to whoever manages each NTSKE server.
>> In this scenario, for the client to know that the server behind the SRV record are trusted by the pool system, it will have to either do end-to-end DNSSEC (and the pool DNS has to support it),
> DNSSEC do not really work that way. But close :-)

Hi Patrick,

I know how DNSSEC works, but I failed at explaining my idea well!

> You must trust whoever is doing the validation. You extrapolate that to you having to do the validation, but that builds upon you not trusting (for example) the access provider that runs the recursive resolver for you also do the validation.

Right. I don’t believe trusting the access provider (typically) nearly comes close to the goal of NTS in terms of security.

With “regular NTS” you don’t trust NTS, but rather the chosen TLS infrastructure.  Changing the trust model to rely on DNS doesn’t seem right.

What I meant with the above was that if the client does DNSSEC validation and the pool service does DNSSEC signing you (might?) get the same security guarantees back. There are a lot more TLS capable clients than DNSSEC validating ones, so this doesn’t seem like a good trade-off to me.

>> or the CA used for the server need to be explicitly tied to the pool configuration. If not then your ISP can easily hi-jack the service in a way that’s not possible with “regular NTS”. Or maybe I am missing something. :-)
> I think Christers idea is good(*), as it collapses to "if you trust your DNS, then you can use SRV". This irrespectively of whether DNSSEC is in use or not.
> That trust can be built by either just trusting DNS, trust the validating recursive resolver run by a third party, or you run your own validating resolver on ::1.

This doesn’t seem realistic for most clients, at least of the general pool service.

As Hal said, if your “pool” is all run by one organization it’s really just a cluster and you have reasonable deployment options already.

> Saying SRV can not be used because you do not trust DNS is not working, as we have other issues with NTS if we do not trust DNS.

For most TLS-based security you don’t need to trust DNS (because a DNS-hijacker won’t have the right TLS certificate); I don’t understand why NTS is different. If DNS is lying/hijacked/bad the NTSKE connection won’t work, right?

> NTP Pools rely on us trusting the DNS as the pool is built in DNS as the database.

NTS is an opportunity to improve on that. :-)

I’ll expand on my suggestion regarding the certificate authority above in a reply to Hal’s message.