Re: [Ntp] Antwort: Why Roughtime?

Ben Laurie <> Mon, 18 December 2023 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18CE0C14CE29 for <>; Mon, 18 Dec 2023 06:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Status: No, score=-17.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 UEEsbiVoBmnX for <>; Mon, 18 Dec 2023 06:11:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (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 24477C14CEE3 for <>; Mon, 18 Dec 2023 06:11:36 -0800 (PST)
Received: by with SMTP id d75a77b69052e-425c1d7d72eso525231cf.1 for <>; Mon, 18 Dec 2023 06:11:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702908695; x=1703513495;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dm7m2I1y66MjBA50yy+7oA2b0U2lR4RhXzF6RUdJ3Tg=; b=CuWNsUYkiu/49hDtElkV8naZVATMgHZLsNvQgBsFANZiH9x5TaEm3o72x/ot8F9Qao fE4zFpXEOPjzrVYG5PA0Gd6ooUMqOvK1+7bz8GgCFIO8txvwKlOqa6mPvh05CWEDbEo0 CNB0V1ZbxDVWyMixrRHl1xc3IYHDfNwok9Ep2yBVkqJwQi7WlxHngl1ktbQSU0qdqfy8 YkMVa3Hk9ajkrKIPPqqM2t/WXGv7WwBE5ASlb5OiaNXXSJ+jPYgZkEZSYB2Q7DlaEUTU 1NXpHvp8i/W/IJEonOXH2kRQ7EsJ+xwW4XqPdRaQrP831wGw/fIkfDUoo3TQv9MzKKY2 V11g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702908695; x=1703513495; 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=dm7m2I1y66MjBA50yy+7oA2b0U2lR4RhXzF6RUdJ3Tg=; b=cRUEN43VxI7qvLroLtQp0JGM1B5OE8nZKn1oQDmLTMorFDzSSIoBTMApNs3eEilUTg tdl6+FLi1VnyaFEU6tqJJ+Q5eyaAcWz+J5wMjuMLlJ4SWmiilZTo4JWX1Up8nwx415o8 u2GWx5JHT7N+14je9/DEfDfPrfaN8O2q4LiuKRMHML0qL8U7HCRs+owPxgvmPfabJwaT iLPa7xf/OaBIfb1p8aUTXmtHtIMAG4trUYlKTU81iGi95GVmW5OpnQT+7P8X3JEOsUHi lMCyIr4GcHk5lHmK9Js0gW2g94bp5tca5r6Xp1jg9V5P+HVBP/9VVNKRLyfzpqlI2koo Wlyg==
X-Gm-Message-State: AOJu0YxESW159v3yBMX3HTGiF8ZPhwdsmF64fIorhIgT5adE5KyFXwFh kBSzIaAleiqWjOXE7oWkto+R0ZKoQGBsBTAoHyb5xgz1ydDG
X-Google-Smtp-Source: AGHT+IEt25NseFUObWyLWkZd6neHv+tDnOGtXIiUvx+mb43GoTF2TyENBMiBa4SS+M5f1mEP3wfhvxcMPtoy7UJvcXg=
X-Received: by 2002:a05:622a:103:b0:421:c331:7df4 with SMTP id u3-20020a05622a010300b00421c3317df4mr391830qtw.18.1702908694750; Mon, 18 Dec 2023 06:11:34 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Laurie <>
Date: Mon, 18 Dec 2023 14:11:09 +0000
Message-ID: <>
Cc: Hal Murray <>,
Content-Type: multipart/alternative; boundary="000000000000d65242060cc95312"
Archived-At: <>
Subject: Re: [Ntp] 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 14:11:40 -0000

On Mon, 18 Dec 2023 at 08:09, <>

> Hey Hal, all,
> I whole-heartedly agree with Hal's points.
> In June, Martin and I sent a lengthy mail containing feedback on the
> Roughtime draft.
> Perhaps there was too much in there for these points (malfeasance
> reporting is unclear what it would actually do; no malfeasance report
> doesn't mean good intentions; any security protocol could just ditch key
> lifetimes and go back to pre-shared keys [and thereby eliminate TLS] with
> little extra work, NTS too) to really come through succinctly, but all of
> them have been concerns of ours as well.
> Further, I still think it is a bad idea to say 'We solve the
> chicken-and-egg problem of bootstrapping' with what seems like a mere
> reduction of a security feature (key lifetimes). It feels more like
> navigating around one of the operational ways in which the problem
> manifests rather than solving it (which makes sense, since the problem is
> probably fundamentally unsolvable). And to be clear: I'm not saying at all
> that it's bad to use long-term keys - I am just saying it's dangerous to
> imply that this is the bootstrapping solution the world has been waiting for

I think you've both missed an important point: if an NTS server gives me
incorrect time and I point that out, there's no way for you to know, in
general, whether my claim is true or not. With roughtime, I can present

Besten Gruß / Kind regards,
> Kristof Teichel
> __________________________________________
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.: +49 531 592-4471 <+49%20531%205924471>
> E-Mail:
> __________________________________________
> -----"ntp" <> schrieb: -----
> An:
> Von: "Hal Murray" <>
> Gesendet von: "ntp" <>
> Datum: 17.12.2023 05:35
> Kopie: "Hal Murray" <>
> Betreff: [Ntp] Why Roughtime?
> 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.
> _______________________________________________
> ntp mailing list
> _______________________________________________
> ntp mailing list