Re: [Ntp] ntpv5 requirements

Miroslav Lichvar <mlichvar@redhat.com> Tue, 14 February 2023 08:48 UTC

Return-Path: <mlichvar@redhat.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 B7F89C14F6EC for <ntp@ietfa.amsl.com>; Tue, 14 Feb 2023 00:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 0I2VcB1JOMa2 for <ntp@ietfa.amsl.com>; Tue, 14 Feb 2023 00:48:24 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 39944C19E105 for <ntp@ietf.org>; Tue, 14 Feb 2023 00:48:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676364502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l9vQp+UfI1QiDzCwvDfmmSsEUBtlNimSS+ab8t9Bhuk=; b=HTVV9OyZUHS1VPJZ2qq0evEAfEQ/otm7ihuLnwZXIjJADJrzyeXBx+phAUyyWUNSDiEoEF uC1F1m3HhpOBK8EWeDy6sbM1eaBGYLKVCD+CbTIG+YKt9YkJv5lzdCVDyIqUcg4c3eQS+1 YOviO4+rbeEP1QL/mtKJjNUaqqzIz/g=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-122-IF9fBIuvMFmZfRnjb48cBQ-1; Tue, 14 Feb 2023 03:48:21 -0500
X-MC-Unique: IF9fBIuvMFmZfRnjb48cBQ-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C5DD685A588; Tue, 14 Feb 2023 08:48:20 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5586B4010D5F; Tue, 14 Feb 2023 08:48:19 +0000 (UTC)
Date: Tue, 14 Feb 2023 09:48:19 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Doug Arnold <doug.arnold@meinberg-usa.com>
Cc: NTP WG <ntp@ietf.org>
Message-ID: <Y+tK0/ThzDSRFlXu@localhost>
References: <DB8PR02MB5772E45732B25646F7CAE211CFD99@DB8PR02MB5772.eurprd02.prod.outlook.com> <Y+pgBgc/5dJ9wtAP@localhost> <AM7PR02MB576579AFC2D5733F7F112F03CFDD9@AM7PR02MB5765.eurprd02.prod.outlook.com>
MIME-Version: 1.0
In-Reply-To: <AM7PR02MB576579AFC2D5733F7F112F03CFDD9@AM7PR02MB5765.eurprd02.prod.outlook.com>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/dooAnw9rsNu481UiEMCK9HJrLM8>
Subject: Re: [Ntp] ntpv5 requirements
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, 14 Feb 2023 08:48:29 -0000

On Mon, Feb 13, 2023 at 06:10:44PM +0000, Doug Arnold wrote:
> I think that he sees TESLA as super-efficient. One could generate 1 key per second to be used by all clients that second, never open a TLS channel, never look up keys in an a key index table, never encrypt a cookie.

There would still need to be some asymmetric operation and
certificates in order to authenticate the first key for the client, so
something like NTS-KE/TLS would need to be used anyway.

TESLA requires a reasonably accurate clock to be able to tell when a
key is disclosed. Some clients probably wouldn't want to wait more
than few seconds for the key (e.g. to set the clock on boot), so the
clock would have to be kept accurate to a second.

Some devices have very unstable clocks (e.g. in virtual machines) and
would need to poll the server very frequently to stay within that
limit. Some computers don't have an RTC and lose time while suspended.
There are other reasons for unexpected steps of a clock.

If the clock is not kept accurate, it completely breaks the security,
just to avoid decoding a cookie. I don't think that is acceptable for
NTP. 

-- 
Miroslav Lichvar