Re: [Ntp] Roughtime: Protocol mechanism for root key rotation?

chris - <> Thu, 14 December 2023 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F253C14CF13 for <>; Wed, 13 Dec 2023 18:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Status: No, score=-2.103 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nGzyKebKTVmX for <>; Wed, 13 Dec 2023 18:08:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42b]) (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 (Postfix) with ESMTPS id 40754C14CEFF for <>; Wed, 13 Dec 2023 18:08:00 -0800 (PST)
Received: by with SMTP id d2e1a72fcca58-6d099d316a8so3790497b3a.0 for <>; Wed, 13 Dec 2023 18:08:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702519679; x=1703124479;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JvoKjvUsFgY40VRemF85C/hnkSzf5yDNw1ZRPV4wHkI=; b=bIH+4DChwUT5GlfAtqPQOW8zaOszRYaqAeGHokOWiOel10bt8JNCfiTBbek2kOEFSS EA68zdIlW1baALqPDFRc7rJ4iRbtRn4Y7Bgxh3d0h+qcesPTowakq4jEVYsqqMGDrO3H FPW1YJ10qxNSCLL2oZmyUsFpAkbe4tYjUiFUFSLKFdROx3ipo7XffRGoUcFXmzFhBymS 98P0a0/zFGWf7yXNSuopGF4teNgWaO4rmNPUR0RLCz2d8XXEx0lCFlM+fTC2bjHZy7qf m0LBmSz1QHJElFMwo4Vgy2XiIkX2utr4gTD0aVC2v1GnUIlwpN851Et2nFL83BHAh7OD +SUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702519679; x=1703124479; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JvoKjvUsFgY40VRemF85C/hnkSzf5yDNw1ZRPV4wHkI=; b=n6vfZk9P+bc715z21/8kC+JcV38lSJbX/zba8IjIUZhMY+AWbgwrcFSl7Qh8eXWNZT gnEBTC+AZrr0Uwr1xpfWotNUxok2GqOARi1HbLNZmms9T8QEpTItlJxuG2fs8GXSTSoi 6YjivIM5Vp+Raan/c02x3DZ2v33lgY+mFKb9+ImI8vHDmN+M2VpRJxRVGQNDAc1/fKN7 Q92jfyUpn+2D9U6aG2HRi6fv0Ehl5eQ2f52CH0a5mm2Ky+snjLwEaeNogtIdbsWZ5uVn NmEvkfBgRLmO1NWXBS9ldU6jj5CMBlKQwZK5G4NFfVIOxuB/VfBIHCAGTJUBWDuviqlM rldA==
X-Gm-Message-State: AOJu0YxO8xkAKM5MEyemy86LBjkiI0Fm598qc0R8quFmJnRdYcNAdpD6 yErFL0yjHUIXcijjP2LxPDZXM1UZ0nYMFUo0feo=
X-Google-Smtp-Source: AGHT+IEl7O6BT+RkYQ1Fh1pE2wLN2aU2sew23hlXK8J70BFDeRGWHKOHseESQstIhlG+ADQhaAnbQSbrnQd8w4N22gM=
X-Received: by 2002:aa7:8884:0:b0:6ce:2731:a079 with SMTP id z4-20020aa78884000000b006ce2731a079mr11087275pfe.40.1702519679296; Wed, 13 Dec 2023 18:07:59 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: chris - <>
Date: Wed, 13 Dec 2023 18:07:48 -0800
Message-ID: <>
To: Hal Murray <>
Content-Type: multipart/alternative; boundary="000000000000b52e01060c6ec089"
Archived-At: <>
Subject: Re: [Ntp] Roughtime: Protocol mechanism for root key rotation?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Dec 2023 02:08:04 -0000


As I understand things, there are 2 uses for Roughtime.  One is
> establishing
> proof that a server is giving bogus time.  The other is getting time when
> you
> don't yet know the time.

Admittedly I wasn't around for the adoption call, so I'm not familiar with
all of the use cases that were discussed. But if I may, I'd like to suggest
a refinement to the first use case you mention. It's not merely about
detecting misbehaving servers; it's about getting a rough measurement of
time even when some fraction of the servers are misbehaving. Indeed, a
healthy Roughtime ecosystem (i.e., one with many independently operated
servers, see can
provide this even if a server is simply misconfigured or not available. I
like to think of Roughtime as "rough consensus", but for time :)

Also, to add a third class of applications: Roughtime is popping up in some
web3 contexts, e.g., There is
also, which uses a server list.

If you are going to rotate a key, and you want to use Roughtime to get the
> time when you don't know it yet, you have to discuss how long a key will
> be
> valid.

This gives me an idea (perhaps you have a similar idea): The root key
should also include a validity period, similar to the way the online key
does. That way if verification fails due to the client having an
out-of-date public key, the client has an explanation once it learns the
consensus time and can prune it from its list of servers.

> If I put the key into an IoT type device, put that device in a pretty box
> which goes into the supply chain, how long before it gets plugged in?  Are
> you
> going to print a use-before date on the box?
> But that's the easy case.  The interesting case is when the device is part
> of
> a critical infrastructure and goes on the spares shelf.  How long will it
> sit
> there?  Think decades.

I'm a bit biased because I mostly live in the web space, but this worries
me. It might be fine for private Roughtime deployments, but for general
purposes I don't think it's a good idea to hardcode the root public key
without a plan to rotate it. Otherwise, we would have the same opsec
requirements for the root public key as we do for root certificates in the
web PKI. Indeed, root stores are regularly rotated, as part of a root
program implemented by web browsers like Firefox and Chrome.

That said, there are probably things we can do to make updating root public
keys easier. As far as I know, at the moment Roughtime operators are just
publishing public keys on websites, such as or datatracker
(draft-ietf-ntp-roughtime-08 has a list of servers) or potentially on
mailing lists (
One thing we can try is standardize a ".well-known" HTTPS endpoint for
fetching a server's current public key (many IETF protocols do a similar
thing). That way clients that know the consensus time can have a chance to
update their server config list (using the web PKI as a trust anchor).

> As far as I can see, if the problem is getting the time from a cold start,
> you
> have to distribute a long lifetime key and run the servers that will
> support
> that key.  Does DNSSEC work without time?  If not, you have to run the
> server
> on a stable IP Address -- stable for the length of time the key will be
> valid.
> Does Roughtime offer any advantages over using NTS with a self signed
> certificate with a long lifetime?

Here I'll just say that Roughtime is a deployed protocol with a significant
amount of real world usage. The draft is adopted, so the goal of the NTP WG
should be to specify the best-possible version of this protocol so that we
can migrate to it as soon as possible.

Chris P.