Re: [Ntp] NTS pool support

Ask Bjørn Hansen <ask@develooper.com> Mon, 22 July 2019 06:35 UTC

Return-Path: <ask@develooper.com>
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 55265120142 for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 23:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 cXiXsYJh7FaG for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 23:34:58 -0700 (PDT)
Received: from mx-out1.ewr1.develooper.com (mx-out1.ewr1.develooper.com [139.178.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id 2781E1200EF for <ntp@ietf.org>; Sun, 21 Jul 2019 23:34:58 -0700 (PDT)
Received: from mbox1.develooper.com (unknown [147.75.38.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx-out1.ewr1.develooper.com (Postfix) with ESMTPS id 20FDA6E04B4 for <ntp@ietf.org>; Mon, 22 Jul 2019 06:25:35 +0000 (UTC)
Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id F3D5F176124 for <ntp@ietf.org>; Sun, 21 Jul 2019 23:25:34 -0700 (PDT)
Received: (qmail 18267 invoked from network); 22 Jul 2019 06:25:34 -0000
Received: from c-98-248-50-174.hsd1.ca.comcast.net (HELO ?10.0.200.100?) (ask@mail.dev@98.248.50.174) by smtp.develooper.com with ESMTPA; 22 Jul 2019 06:25:34 -0000
From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= <ask@develooper.com>
Message-Id: <C0905BA5-14F8-4F03-A1B7-499582E42C04@develooper.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3924A1B9-13AD-4666-9552-DAC88DE00E40"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 21 Jul 2019 23:25:20 -0700
In-Reply-To: <20190721221505.ECA5C40605C@ip-64-139-1-69.sjc.megapath.net>
Cc: Christer Weinigel <christer@weinigel.se>, ntp@ietf.org
To: Hal Murray <hmurray@megapathdsl.net>
References: <20190721221505.ECA5C40605C@ip-64-139-1-69.sjc.megapath.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0npmJHgIhi-CrGzLA0pC5aw6xGQ>
Subject: Re: [Ntp] NTS pool support
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: Mon, 22 Jul 2019 06:35:00 -0000


> On Jul 21, 2019, at 3:15 PM, Hal Murray <hmurray@megapathdsl.net>; wrote:
> 
>> Here's my naive suggestion on how to handle NTS pools.
> 
> I think you have to be very careful about what you mean by "pool".  In most 
> NTP discussions, "the pool" usually means pool.ntp.org, a large collection of 
> NTP servers run by volunteers.  Trust and secure don't make sense with that 
> type of operation.  There is no point in using NTS.

I don’t think that’s true. Implemented right a client could know for sure who it’s talking to.

With short lived certificates, the client could know that the pool system had validated the monitoring data within X hours/days. It could be a solution to having a client know if the server had been removed from the pool system.

One suggestion for this that’d work, I think, with Christer’s SRV suggestion would be (as I suggested a few days ago) to configure the client with a certificate authority that’s managed by the pool system and only trust this CA for servers returned by that specific pool DNS name.  (Basically Christer’s TLSA suggestion, but for clients not doing DNSSEC they could configure the CA in their configuration).

The servers participating in the pool would (automatically) request/get an updated certificate every so many days.

This would be an improvement over the current system in that the client will know for sure who it’s talking to and that the server it’s talking to is part of the pool.

(DNSSEC would still be an improvement in that the client would know the particular DNS response was generated by the pool system and not “improvised”, but it wouldn’t be required for NTS to work).

(Another version, as per what Ragner Sundblad suggested last year in https://tools.ietf.org/html/draft-dansarie-nts-00#section-8 <https://tools.ietf.org/html/draft-dansarie-nts-00#section-8> would be to require the pool system to run the NTSKE servers and have another key exchange method with the servers. I think that proposal underestimated the number of distinct clients using the big public pool-like systems (NTP Pool Project and NIST, as two of them).  Christer’s proposal would support “load balancing” the NTPKE work better).



Ask