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
- [Ntp] Pool and DNS Hal Murray
- [Ntp] Antw: [EXT] Pool and DNS Ulrich Windl
- Re: [Ntp] Pool and DNS Marcus Dansarie
- Re: [Ntp] [EXT] Pool and DNS Neta R S
- Re: [Ntp] [EXT] Pool and DNS David Venhoek
- Re: [Ntp] [EXT] Pool and DNS Neta R S
- Re: [Ntp] Pool and DNS Hal Murray
- [Ntp] Antw: [EXT] Re: Pool and DNS Ulrich Windl
- Re: [Ntp] Pool and DNS Miroslav Lichvar
- Re: [Ntp] Pool and DNS Christer Weinigel
- Re: [Ntp] Pool and DNS Christer Weinigel
- Re: [Ntp] Pool and DNS Miroslav Lichvar
- Re: [Ntp] Pool and DNS Leif Johansson