Re: [Ntp] Pool and DNS

Christer Weinigel <christer@weinigel.se> Tue, 08 November 2022 15:36 UTC

Return-Path: <christer@weinigel.se>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6DCC14F74B for <ntp@ietfa.amsl.com>; Tue, 8 Nov 2022 07:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ024ZGvtqkO for <ntp@ietfa.amsl.com>; Tue, 8 Nov 2022 07:36:09 -0800 (PST)
Received: from www.weinigel.se (www.weinigel.se [71.19.158.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9F727C14E514 for <ntp@ietf.org>; Tue, 8 Nov 2022 07:36:08 -0800 (PST)
Received: from mail.weinigel.se (localhost [IPv6:::1]) by www.weinigel.se (Postfix) with ESMTP id 424B024902; Tue, 8 Nov 2022 16:36:08 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zoo.weinigel.se (Postfix) with ESMTP id D5BB3405C9; Tue, 8 Nov 2022 15:36:07 +0000 (UTC)
Received: from mail.weinigel.se ([127.0.0.1]) by localhost (mail.weinigel.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe6DD0H_iVwe; Tue, 8 Nov 2022 15:36:03 +0000 (UTC)
Received: from [127.0.0.1] (zoo.lab.weinigel.se [10.20.3.10]) by zoo.weinigel.se (Postfix) with ESMTP id B6A614046A; Tue, 8 Nov 2022 15:36:03 +0000 (UTC)
Message-ID: <ce15694e8615872ad18e22bd81dc58532cbe2002.camel@weinigel.se>
From: Christer Weinigel <christer@weinigel.se>
To: Hal Murray <halmurray@sonic.net>, ntp@ietf.org
Date: Tue, 08 Nov 2022 16:36:03 +0100
In-Reply-To: <20221023053430.6022728C1DB@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
References: <20221023053430.6022728C1DB@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.3-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MrOfgu3iHbKReZS8tyri-SZBuOQ>
Subject: Re: [Ntp] Pool and DNS
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 15:36:14 -0000

On Sat, 2022-10-22 at 22:34 -0700, Hal Murray wrote:
> NTPsec packages the KE server with ntpd so there is no need for that
> protocol. 
>  I don't know of any split implementations.  So as a practical
> matter, it 
> would be hard to put together a pool using that mechanism with
> available code.

Regarding the pool I think I made a suggestion a while ago about using
SRV records for discovering NTS-KE servers.  As I understand it the
major issue with the pool implementation is that it is implemented
using A records which return an IP address.  For example I have set up
a "pool.weinigel.se" which points to Netnod's NTP servers in Stockholm:

pool.weinigel.se.       3600    IN      A       194.58.202.148
pool.weinigel.se.       3600    IN      A       194.58.202.20

But this won't work well for NTS-KE since since most certificate
authorities will not issue TLS certificates for bare IP addresses and
current clients will want to see the hostname for the pool in the
certificate.

Installing TLS certificates with the pool's DNS name on all NTS-KE
servers in the pool will reduce the security to that of the most
insecure server.  Not a good idea unless one really trusts all of the
NTS-KE servers in the pool.  Having the pool run the NTS-KE servers
means that a new protocol will have to be invented to let the pool
issue cookies for the different NTS timestamping servcies.  And this
probably means that the pools will have to have run rather beefy NTS-KE
servers to be able to terminate all TLS connections to it.

My suggestion is to simply move to use DNS SRV records instead.  This
would be very similar to how the current pool works.  The pool would
just be a DNS server which returns SRV records:

_ntske._tcp.pool.weinigel.se.  IN SRV  1 10 4460 sth2.nts.netnod.se.
_ntske._tcp.pool.weinigel.se.  IN SRV  1 10 4460 sth1.nts.netnod.se.

The "_ntske._tcp" prefix is how SRV records allow someone to find the a
specific service for a certain domain name.  In this case it says that
the ntske service using tcp can be found on a port/host.

Doing pool this way will require changes to existing NTS clients, but
it's fairly easy to implement.  In principle the logic is like this:

1. Look for SRV records on _ntske._tcp.$POOL_DOMAINNAME. 
2. If any exist, start using NTS using the new list of servers.
3. If none exist, fall back to the old NTP pool behavior.

This means that the user supplied configuration can stay the same.  A
non-SRV-capable client will fall back to using the plain old NTP pool.
If the user upgrades to a SRV-capable client it can seamlessly
transiton to using NTS.  Current NTS servers will not need any changes,
they behave just as they do now.

Just to try this out, I added client support for SRV records to NTPSec:

https://gitlab.com/wingel/ntpsec

It's a bit of an ugly hack but seems to work.  If I add
"pool.weinigel.se" which has SRV records to my ntp.conf:

pool pool.weinigel.se iburst

it will start using the NTS servers from the SRV records:

     remote           refid      st t when poll reach   delay   offset
jitter
=======================================================================
========
 pool.weinigel.s .POOL.          16 p    -  512    0   0.0000   0.0000
0.0001
 sth1-ts.nts.net .PPS.            1 8   17   64    1   1.8919  -0.1496
0.0812
*sth2-ts.nts.net .PPS.            1 8   18   64    1   1.5605  -0.1534
0.1171

If I use "pool-without-nts.weinigel.se" which does not have any NTS SRV
records it falls back to the old behavior:

     remote           refid      st t when poll reach   delay   offset
jitter
=======================================================================
========
 pool-without-nt .POOL.          16 p    -  512    0   0.0000   0.0000
0.0001
*sth2.ntp.netnod .PPS.            1 u   25   64   37   1.5306  -0.1355
0.1565
 sth1.ntp.netnod .PPS.            1 u   17   64   37   1.5539  -0.1410
0.1307

My patch is just a quick proof of concept.  Someone who knows more
about the NTPsec code ought to see if I have misunderstood anything. 
There a few things I'm already aware of.  The current code will always
look for SRV records, it probably should be a flag to ntpsec to turn
this behavior on.  One might also want to add a flag to say that for a
specific pool NTS must be used to avoid man-in-the-middle-attacks that
can downgrade to plain NTP by filtering out the SRV records from DNS. 
If the ntp client can store persistent data it might also want to
remember "I have successfully used NTS once for this pool, I will not
allow plain NTP any more".

Thoughts?

  /Christer