Re: [Ntp] Antwort: Antw: [EXT] Re: NTPv5 draft

Christer Weinigel <christer@weinigel.se> Thu, 17 December 2020 14:13 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 06A713A0896 for <ntp@ietfa.amsl.com>; Thu, 17 Dec 2020 06:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 idXXahijoucX for <ntp@ietfa.amsl.com>; Thu, 17 Dec 2020 06:13:29 -0800 (PST)
Received: from www.weinigel.se (www.weinigel.se [IPv6:2605:2700:0:2::4713:9e68]) by ietfa.amsl.com (Postfix) with ESMTP id 88D433A0888 for <ntp@ietf.org>; Thu, 17 Dec 2020 06:13:29 -0800 (PST)
Received: from mail.weinigel.se (localhost [IPv6:::1]) by www.weinigel.se (Postfix) with ESMTP id 677B024C29; Thu, 17 Dec 2020 15:13:27 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zoo.weinigel.se (Postfix) with ESMTP id E4E2B1E0ECB; Thu, 17 Dec 2020 15:13:26 +0100 (CET)
Received: from mail.weinigel.se ([10.20.9.10]) by localhost (mail.weinigel.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvP5ydeOw7Ux; Thu, 17 Dec 2020 15:13:24 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by zoo.weinigel.se (Postfix) with ESMTP id 4B7FC1E01BC; Thu, 17 Dec 2020 15:13:24 +0100 (CET)
To: Miroslav Lichvar <mlichvar@redhat.com>, kristof.teichel@ptb.de
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, Dieter Sibold <dsibold.ietf@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>, Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>, james.ietf@gmail.com
References: <20201208150725.GX2352378@localhost> <6d7daa5e-8537-a3a5-a5c3-2468be4c2918@gmail.com> <20201209083800.GY2352378@localhost> <bcec8d14-9af9-96c1-7e71-39569cb7b0ed@gmail.com> <51D0EEC3-F30E-4A0F-9DBA-B8D2A8CFA959@akamai.com> <42E7D41602000042824A10E1@gwsmtp.uni-regensburg.de> <18374174020000D46A6A8CFC@gwsmtp.uni-regensburg.de> <1C64D458020000B5824A10E1@gwsmtp.uni-regensburg.de> <A4CD014B020000F57BE0EBB5@gwsmtp.uni-regensburg.de> <OFE90AD9EF.CD8E14CE-ONC125863A.0036599D-C125863A.003A796E@ptb.de> <20201214123127.GE2540645@localhost>
From: Christer Weinigel <christer@weinigel.se>
Message-ID: <c56c5945-1ff3-6a4f-95b3-df409d7da27e@weinigel.se>
Date: Thu, 17 Dec 2020 15:13:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201214123127.GE2540645@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/KZbDRtKzFBQCdwq9aXkbqraWMHk>
Subject: Re: [Ntp] Antwort: Antw: [EXT] Re: NTPv5 draft
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: Thu, 17 Dec 2020 14:13:31 -0000

On 12/14/20 1:31 PM, Miroslav Lichvar wrote:
> NTP is used everywhere. Some hardware doesn't have enough
> memory/storage to support TLS/NTS. Some computers don't have an RTC or
> cannot be assumed to start with correct time to be able to validate
> certificates. Symmetric keys may not be practical. 

Maybe such small devices shouldn't use NTP.  From what I understand
roughtime might be a better choice.  It only uses a few hardcoded
cryptographic primitives so the size of implementation ought to be
fairly small.  Since a roughtime client is expected to have a hardcoded
list of servers and associated public keys it does not have the chicken
and egg problem of needing accurate time to be able to validate the
certificates to be able to verify a NTSKE server to get time.

Of course, public key distribution is a bit of an issue with roughtime,
but if the big players such as RedHat/Fedora, Debian/Ubuntu and
Yocto/OpenEmbedded/Buildroot curates a list with a couple of hundred
roughtime servers, at least some of those servers ought to survive over
the lifetime of a device.  If a client chooses a half a dozen random of
servers to query from the list and all of them agree on time to within a
second, that should give the client fairly good confidence that the time
is received is correct.

  /Christer