[Ntp] Why Roughtime?

Hal Murray <halmurray@sonic.net> Sun, 17 December 2023 04:35 UTC

Return-Path: <halmurray@sonic.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5715DC14CE5F for <ntp@ietfa.amsl.com>; Sat, 16 Dec 2023 20:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sonic.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LgGxQ2zey0cm for <ntp@ietfa.amsl.com>; Sat, 16 Dec 2023 20:35:02 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E6AC1AE94F for <ntp@ietf.org>; Sat, 16 Dec 2023 20:35:02 -0800 (PST)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (104-182-38-69.lightspeed.sntcca.sbcglobal.net []) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 3BH4Z0E0013840 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 16 Dec 2023 20:35:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonic.net; s=net23; t=1702787701; bh=CVH4Ae9Eu0EozYaElbl5FtajS9SAbDoT9/8HK/0kW8s=; h=To:From:Subject:Mime-Version:Date:Message-Id:From:Subject; b=r8wdlj0/ympaBKIV6yIjRNOm6rm2By95VipMjiUWCKhs28lyaRymS5Veo27LyoQ3k x1ohVKoALmHyI4S/wFrUti+z6OWJEYn1kQ+BCeOdnyF7tIfcokb4SMdStYWgKHVWA7 SvkLZdPqbYe/mRxwmuGqQoLaKR3eiXQuCrFZQ2SNVE1ZO+KrdPLc5Nlap1P7UlSCbW XorBituqNrka7nRQ9NnNn9xtw4NtWaNfEuJVdO1OG4SlpphxGwhb+Eg65HBeqcSkJh R4ekXVCOqOlWfPOwRl92mF6TZMSC8rK5vI76Qpfy8lIGNFuAnZCp6xo7Qp/xdEcgP6 uDI22KD/38u3w==
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 99D6128C1C3; Sat, 16 Dec 2023 20:35:00 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8
To: ntp@ietf.org
cc: Hal Murray <halmurray@sonic.net>
From: Hal Murray <halmurray@sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 16 Dec 2023 20:35:00 -0800
Message-Id: <20231217043500.99D6128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVZcetOKoi9aIbPxJ3lMCXyyL493zcxyxivKI1ECP7DPYRaF2ytr98qx1E8pgKDBe/1n7iTQoL2ps1Zdx9zjv1YmK8JOi20Yfu0=
X-Sonic-ID: C;6CnNo5Wc7hGcVRVnR+6Zsg== M;ZBHio5Wc7hGcVRVnR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-p5uQCz5JNdCg3k6LRXl9ibFiVg>
Subject: [Ntp] Why Roughtime?
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: Sun, 17 Dec 2023 04:35:06 -0000

I think Roughtime has 2 goals:

The first is:
  Furthermore clients may lack even a basic idea of the time, creating
  bootstrapping problems. Roughtime uses a list of keys and servers
  to resolve this issue.

The second is:
  Roughtime is a protocol for rough time synchronization that
  enables clients to provide cryptographic proof of server malfeasance.

Why do we need a separate protocol and separate servers?

For the bootstraping problem, the important idea is key lifetime.  NTS uses traditional web certificates and their root certificate bundle.  The root certificate bundle is distributed and maintained by OSes/distros so NTS doesn't have to operate a separate key distribution mechanism.  That path has a limited key lifetime policy.  If it isn't long enough, we will have to use self signed certificates and invent a new key distribution mechanism.  Roughtime has the same problem so whatever they are planning to use for key distribution can be used by NTS to distribute their self-signed root certificates.

Note that "lifetime" is a potentially ambiguous term.  Suppose you get a certificate with a 2 year lifetime.  That clock starts ticking when you purchase the certificate.  After a year, the useful lifetime is the time remaining, only 1 year.  The clock keeps ticking while the box and firmware are sitting on a retail shelf or the spares shelf.

We should issue a new key every year or so even if their lifetime is 10s of years.  There is no significant cost to a server to support 100s of keys.  The newer ones will have a longer useful life -- last year's key will expire a year before this year's key.

What is Roughtime's target market?  What sort of key lifetime does that need?
How about traffic volume?

On to server malfeasance.

I'm curious about the proof part.  Is Roughtime planning to take server operators to court?
Where else would you need a strong proof as compared to "Hey, your server is broken!"?

The NTP pool has a monitoring system that drops a server when it doesn't respond or returns time that is too far off.  It sends email to the operator.

NTS already signs NTP packets and that includes a nonce field.  The catch is that the key used for signing each packet is a client-server working key rather than a private key of a public/private pair.  We can fix that by adding a slot to NTS-KE which is the KE server signing the working key with it's private key.  (If the working key is exposed in a malfeasance report, the client needs to run NTS-KE again to get a new one.)

Wikipedia says;
  Malfeasance is the willful and intentional action that injures a party.

The proof scheme described by Roughtime doesn't prove the "willful and intentional" part.  Servers screwup because of bugs in software, firmware, or hardware as well as network troubles and bad luck and inadequate operational procedures.

There is another aspect to consider.  The lack of malfeasance reports doesn't prove correct operations.  If a bad guy takes over a server, he can respond correctly except to the system he is attacking.  You can't depend on monitoring by other sites.

In recent mail, Chris mentioned "consensus".  NTP already does that.  Does Roughtime have better heuristics for consensus than NTP is using?

Have I missed something that Roughtime does and NTP can't do with a simple extension?

These are my opinions.  I hate spam.