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

Daniel Franke <> Mon, 18 December 2023 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2050C14F61D for <>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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_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 e5jaQh8ab8EN for <>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
Received: from ( [IPv6:2001:4860:4864:20::30]) (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 5C33AC14F615 for <>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
Received: by with SMTP id 586e51a60fabf-203ba1328d1so940524fac.0 for <>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702920737; x=1703525537;; 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=yh1XyrG0yCP+2/hdayB5poCcv7fGMGa+6726VAylJFo=; b=kC3XjInUwxN3Cbc+LM2RJtKtM10diEGk2HkZCpkMS3H7YFjCEulu13/TDpXrEJfsHC JJdDunWyvVkRMT6wrY1PoSEkIBW30YdET1h1V8iRUGF1BTpITGC/G0K3VmOHx005/6Gz qb3fizi7GXqLoYkVeBOuqtXDQ163esjn/0U0cdEXE+OQ70emdZrWHJQp6a7XFB7wvLe9 THQSjWD/81fJvJK+1PXeP9ExFTCbwQGXRz0i+FqeOz0aBEI5AUhKXy857POWOJsfF1xZ wcHk5hSJlcsnvSkWA6BZf0RDIYTuOO91w71vBjbEFuPveWGnKXIswqG3ijvG9/8ahLq4 59JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702920737; x=1703525537; 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=yh1XyrG0yCP+2/hdayB5poCcv7fGMGa+6726VAylJFo=; b=IR6ErclQH+Gbz7FeNg5ZMO1Zw9BfqhY9XXTfmp5d3bou8mo/Jb9d85DISnh34CmaXF Vd+YzlbokKyV/oK4oem6TOEi2p71p3ffhVzrLwCGweAEtZI5HBnTYYg5LuUwlBYZscLO OTEJjRzKOwFlcVLYTMqweq7l0AwADwpN79FN6M+NooPiiGaIiuZwybpm/1tDUbIjhEMT AePp3zdix60DoOuDhSPgAPsmVln9QMAegAjbX1tPiLMCQXhsL6bs3zTFxhnxJNGZ/3cc MGnuIafZyLnFghxYwzW8KFtpVsaOafkP3CggaEk7XiZI4TBmx+SiQINJoexg9i7OBwEP ejug==
X-Gm-Message-State: AOJu0Ywq5QT6Y+09j2oOQm6JnIcUBwM0xB1h59z6SnLfhgtxNZQembbV 9wDq91WXuw/rHnn2gr7uTuGHWGZDcA3Di1akeIE=
X-Google-Smtp-Source: AGHT+IHbvVmns5W7Fu4njYuRLjZixkl52XrNIWf4/bUGh1uHij99z2CKM1WJo+ulh9GJ5p7HG5eThezYQfhA5oyTnek=
X-Received: by 2002:a05:6871:7a2:b0:1fa:db9b:4080 with SMTP id o34-20020a05687107a200b001fadb9b4080mr15127686oap.22.1702920737305; Mon, 18 Dec 2023 09:32:17 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Mon, 18 Dec 2023 12:32:06 -0500
Message-ID: <>
To: Watson Ladd <>
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:32:19 -0000

+1: Roughtime needs to be its own thing. Trying to implement it as an
NTP extension is just going to be a complete mess.

On Mon, Dec 18, 2023 at 12:24 PM Watson Ladd <> wrote:
> 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.
> Sincerely,
> Watson Ladd
> --
> Astra mortemque praestare gradatim
> _______________________________________________
> ntp mailing list