Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?

Watson Ladd <> Mon, 18 December 2023 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1CCEC14F5E2 for <>; Mon, 18 Dec 2023 09:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 WaHXaedA1eun for <>; Mon, 18 Dec 2023 09:24:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (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 412C6C14EB17 for <>; Mon, 18 Dec 2023 09:24:12 -0800 (PST)
Received: by with SMTP id 41be03b00d2f7-5c66bbb3d77so1423898a12.0 for <>; Mon, 18 Dec 2023 09:24:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702920252; x=1703525052;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TeQtbIj5ke2kOHuvU9m4Ykphhm7gwjdhKMqqEy5OS1A=; b=J+6gRkpQRrjEC0NUwDU4GbSRt0gvvXmK4vMIprvLRyLGaROJMh0PM97JVfiStEZWCI /8O/tyracksPbaawXTfb/Fs9tDHw5FbuR6bazwghZIjg3Y3XoEPi4xdnn48VoMJ8HG3L mnhgDxOl8zBnUKj7XMAoxiNn7SRvD0ThvJsrP5YEUXOpmlq8rookT8cu3iYoziOdxuFQ sHiLSPIL/6RnpHVcoCqEsGHUkHwwSry8pS43YR3bXCZmTiFpI7fIXWi+HTTrCdIy/7b1 PdRS5i2NKrSr+ERBVQ0kVLUm6mJEVnut2lpUmVrIoDO7Mm8dEC/wrsTG/B0tt7Ojwh+X vTIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702920252; x=1703525052; h=content-transfer-encoding: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=TeQtbIj5ke2kOHuvU9m4Ykphhm7gwjdhKMqqEy5OS1A=; b=qQlX/PffvUFjt1lmX0aRgLQoQ3YqDZLNTq3q1w2ynQ87/0voEc/07w0eljPAw+/0lH fKmcI5pi8p6k9H88cPVO5/Z569NS8LoXPA7KhIIuvYVJHDNgfmYgUxDWg9+haYo4C+Zg Ju0YiF4trADqIEqA7KO2wtkoBrDesULTVMxQEj6ZxrmChPPPfC8kdiFYYHUD1k1ZJsIW mCKXg5CR/kijT45MLuUVFIK2eSGeEyMPYCRTjqsdsIn+KTp4yMNXHKJ1OYkwVudNWdtr REs3Jbjlsra291f3drPV8GqywGtGoTyhYk7CVDVu7fvH8bavUvgtk5RA47J49HtneQ+D 4d+Q==
X-Gm-Message-State: AOJu0YzdvIcJ8bHfDSpzq/9S2UpmCsQpytxn86bY83FahAKv5zkji4Dp 9q9JQa2oL5WisehwKeRYUaNuEwKXqBumSXAYXYDGWThc
X-Google-Smtp-Source: AGHT+IFg+Kzsw0os8gXFNbu0juc769f9zKMB/KShKUOwCDuDVXrKdzfHxpeINjB971PjzCK8hiJsjOtcgRMxy7fJIh4=
X-Received: by 2002:a05:6a21:186:b0:194:8a59:8036 with SMTP id le6-20020a056a21018600b001948a598036mr620749pzb.50.1702920251533; Mon, 18 Dec 2023 09:24:11 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Mon, 18 Dec 2023 09:24:00 -0800
Message-ID: <>
Cc: Ben Laurie <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?
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: Mon, 18 Dec 2023 17:24:12 -0000

On Mon, Dec 18, 2023 at 8:33 AM <> wrote:
> Hey Ben, all,
> It's not, I think, so much that we missed it (Martin and I, can't speak for Hal - although he does mention the feature explicitly).
> I think it's more that we don't believe it's as useful as others seem to think (honestly, I think this is explicitly talked about in our mail from June, too):
> I've never heard a user express that they want to be able to get false time and then report it.
> I have heard users express that they want to get correct time.
> Those two goals are not the same, and the logical chain leading from the former to the latter (where I'm supposed to believe someone is trustworthy from the fact that I don't currently have a report at hand about misbehavior from them) just seems far-fetched to me.

I never heard users express that they wanted to catch misbhaving CAs:
they wanted properly behaving ones. But to make them behave properly
we created CT logs, so that instances of CA misbehavior couldn't be
hidden. And those CT logs get monitored to ensure trustworthiness via
similar mechanisms to Roughtime, even though most users of CT logs
don't directly interact with those mechanisms.

Likewise the possibility of detection raises the stakes for
misbehaving servers, even if most users won't.
> And this is just exacerbated by putting it next to Roughtime's other most-advertised feature: use in bootstrapping phase.
> If a device has just booted up and has close to zero knowledge, I think it extra unreasonable to rely on malfeasance reports that the device may simply never have gotten.

Devices don't rely directly on reports, just as in the WebPKI browsers
don't look at the contents of MDSP mechanically. However, without
reporting vendors have no way to reevaluate the trust relationships.
Even if this reevaluation is not instant it still limits the impact of
a compromise.

> Lastly, if malfeasance reporting IS deemed an important feature by someone, I again agree with Hal that it could be put into any protocol (e.g. NTP, with an extra extension field).
> It is definitely Roughtime's more complex feature, but it would also not be terribly much to ask of other protocols IMO.

How would you put it in? Signing the response takes significantly
longer than you want in NTS. Having a long term identity runs at cross
purposes to relying on the WebPKI. I'm not opposed to possible
integration but I think the security models and synchronization goals
are pretty opposed.

Watson Ladd

Astra mortemque praestare gradatim