Re: [Ntp] Antwort: Why Roughtime?

Daniel Franke <> Mon, 18 December 2023 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C567CC14F682 for <>; Mon, 18 Dec 2023 10:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Status: No, score=-7.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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mc5thpkYw7pw for <>; Mon, 18 Dec 2023 10:58:32 -0800 (PST)
Received: from ( [IPv6:2001:4860:4864:20::29]) (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 B4319C14F6AF for <>; Mon, 18 Dec 2023 10:58:32 -0800 (PST)
Received: by with SMTP id 586e51a60fabf-1f066fc2a2aso1090421fac.0 for <>; Mon, 18 Dec 2023 10:58:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702925911; x=1703530711;; 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=6nC6PqSB0x17kIhTQAfsCdrGRbgVup7Hxk8B3HTV/9A=; b=EK/+PAO5DXUHYf/HQUvLr9ahRzq2iPNJ/7c0lqhfZGZWK545YJ8z92dNyqMwQ9pkjs +vdhc6HUqLkUobOYAvAWWbmH1CEv95QM17TmpIBGPNhwDmGAsEgJlRZTSAH8eeGPE80H 4mkc0krkVsl/G/21VlzSCUhxS73f/LF6ihS6+LuAgTkr0+I/NyO1DLz9cc5dlfcQhE+Q HO6mjUlO5gcTcZ5rnBxgS5Dej3wPDuIRUiT7jZzW5McUHUU4ZuDx3XRmQEeRRYKIAUFt POgJ82/EtxRtxzafRNDvk+Yz3U7P5O/tW0DuZkHKmNiNJQwKU+HWUfgec9JCUCswiDZ0 tXIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702925911; x=1703530711; 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=6nC6PqSB0x17kIhTQAfsCdrGRbgVup7Hxk8B3HTV/9A=; b=ioiQ/Xkp0zLx9ngaE49gyh0LxV0+q4BW+mWrFP4mbYn1hn9+wm+stfT1/FO4iIaioc sr1olpPm++CMUAgvPdMM0Mp0ZLoGhJgUmgTUiEd2+5psoR22/Ig6jVNrb3WPu1XYnhs7 LIS9veeiFD57d3xmfAwk6kuv3a1XOBHiU4jPc3QKzSoDhUJ62wgQg4UD7HkpwqZQGEdi jG3nfBgoYQzEL+OsZDzboSjCowyESskPf0I/YOJELA6GKiJsX0g7+qLfCYN3pjBEsg7h j9iav5LVcdKG+iaHX8FwlzS1+lGUrjk5kBWhLU6HhySBNbaWlRaB/5UIl39bg78F2CmY X+Tw==
X-Gm-Message-State: AOJu0Yzv9n5NIjXB+6VcB9luQQh9ElDt6GwY096lju7AV3/4lsRf/TiO i6NmUupOFMQDvmL/K76RpfZ6zD7XvHkf8VwtYfo=
X-Google-Smtp-Source: AGHT+IEj3qhIuEUB5joBQ4ssMNXIkXjjO2tnciNz1D8Wvyoo9PXp0zRo5xNtRi5Q/zQ3QLCp4J55SpRkb3C0zgsz9ws=
X-Received: by 2002:a05:6870:40ce:b0:1fa:e1c8:8bb0 with SMTP id l14-20020a05687040ce00b001fae1c88bb0mr9582304oal.28.1702925911449; Mon, 18 Dec 2023 10:58:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Mon, 18 Dec 2023 13:58:20 -0500
Message-ID: <>
To: Hal Murray <>
Cc: Ben Laurie <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 18:58:34 -0000

On Mon, Dec 18, 2023 at 1:18 PM Hal Murray <> wrote:
> We can get the evidence with a minor addition to NTS-KE.  We don't need a new
> protocol and new set of servers.

No we can't. NTS-KE runs once per session. Roughtime evidence needs to
be constructed as a part of every query and response and servers need
to be polled in a specific pattern that isn't ideal for NTP.

> What are you going to do with that evidence?  If a server is broken and
> returning bad time to everybody then it will be easy for anybody to confirm
> your observation.  Is evidence good for anything other than a legal battle
> when a malicious server is returning bogus time to only your IP address?

The idea is that evidence gets uploaded to something akin to a CT log,
which then gets polled automatically by other clients, which will then
automatically never trust that server again. A server that sends bad
time once will shortly have all its traffic dry up unless and until a
new key is issued after review of the incident.