Re: [Ntp] NTP Security (was NTPv5: big picture)

Hal Murray <hmurray@megapathdsl.net> Sun, 17 January 2021 09:25 UTC

Return-Path: <hmurray@megapathdsl.net>
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 2C2123A0D12 for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 01:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxgUao5i-BKp for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 01:25:37 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 063C93A0D06 for <ntp@ietf.org>; Sun, 17 Jan 2021 01:25:36 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 8DBF640605C; Sun, 17 Jan 2021 01:25:35 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Watson Ladd <watsonbladd@gmail.com>
cc: NTP WG <ntp@ietf.org>, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Watson Ladd <watsonbladd@gmail.com> of "Sat, 16 Jan 2021 16:43:21 PST." <CACsn0cmhJhhM4Ab64RXRknRi+jM-SugFYvA+71tSV4c0XXmAgQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 17 Jan 2021 01:25:35 -0800
Message-Id: <20210117092535.8DBF640605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/xLhUgBq2T0j1Q4boIlsrjjcco5E>
Subject: Re: [Ntp] NTP Security (was NTPv5: big picture)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Sun, 17 Jan 2021 09:25:38 -0000

watsonbladd@gmail.com said:
> I neglected to mention my now expired https://datatracker.ietf.org/doc/
> draft-ladd-nts-for-ntp-pool/ as an example of this approach.

That mentions ACME several times.  I don't know anything about ACME.  A few 
words about what it does might be helpful.

 From page 3:
> Clients MAY periodically resolve the pool associated domain
> names to confirm the server is still trusted by the pool.

That doesn't work.  The DNS servers for the pool reply with several IP 
Addresses out of many in the pool.  If a client asks again later, they will 
probably get a different subset.

This issue comes up even without NTS.  There is no way for a current pool 
client to verify that a server is still in the pool.

I think it should be easy to fix.  The pool DNS servers would have to support 
a new mode, something like an A record for d.c.b.a.pool.ntp.org that returns 
the address if the address is still in the pool.



-- 
These are my opinions.  I hate spam.