Re: [Ntp] Getting started using NTS -- clock accuracy vs certificates

Danny Mayer <mayer@pdmconsulting.net> Tue, 02 August 2022 14:25 UTC

Return-Path: <mayer@pdmconsulting.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 826DCC13C514 for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 07:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 1PFUg5oOhRCw for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 07:25:35 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E74FC13CCD7 for <ntp@ietf.org>; Tue, 2 Aug 2022 07:25:34 -0700 (PDT)
Received: from [192.168.1.156] (pool-108-26-202-2.bstnma.fios.verizon.net [108.26.202.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4Lxy2L5cMvzMP2n; Tue, 2 Aug 2022 14:25:30 +0000 (UTC)
Message-ID: <31ef4988-c6c5-37f2-8221-e9f3bb1a450b@pdmconsulting.net>
Date: Tue, 02 Aug 2022 10:25:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
From: Danny Mayer <mayer@pdmconsulting.net>
To: Miroslav Lichvar <mlichvar@redhat.com>, Hal Murray <halmurray@sonic.net>
Cc: ntp@ietf.org
References: <mlichvar@redhat.com> <YueT8bAiTeM+nTZv@localhost> <20220801210637.D395628C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <YujtTu1YYEvhg2Hv@localhost> <21466cc0-dbdb-102c-2886-46c7b22d1348@pdmconsulting.net>
In-Reply-To: <21466cc0-dbdb-102c-2886-46c7b22d1348@pdmconsulting.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/n-zCl1BgsKnnkiG_JCeXxS6__Yk>
Subject: Re: [Ntp] Getting started using NTS -- clock accuracy vs certificates
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, 02 Aug 2022 14:25:40 -0000

I forgot to add that you should not be using IP addresses in your 
configuration of NTP Servers. Addresses can and will change and those 
servers can be retired. The example of the Australian server being 
retired and the address continuing to be bombarded with NTP requests for 
years afterwards comes to mind. Publicly available NTP servers are at 
the whim of the operators of those servers.

Danny

On 8/2/22 9:39 AM, Danny Mayer wrote:
>
> On 8/2/22 5:24 AM, Miroslav Lichvar wrote:
>> On Mon, Aug 01, 2022 at 02:06:37PM -0700, Hal Murray wrote:
>> Using the numerical IP address as the "host name" in the certificate 
>> would
>>> avoid the DNSSEC tangle.  That seems like a reasonable convention 
>>> for long
>>> lived certificates.
>> Yes, including the IP address as a Subject Alternative Name in the
>> certificate could be a very useful feature.
> Not really. IP addresses are not a reliable constant. You don't avoid 
> the DNSSEC tangle because DNSSEC needs accurate time (relatively 
> speaking) to work at all. This is the bootstrap problem.
>
>
> Danny
>