Re: [Ntp] Antwort: Why Roughtime?
martin.langer@ptb.de Mon, 18 December 2023 15:21 UTC
Return-Path: <martin.langer@ptb.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B90C14F68B for <ntp@ietfa.amsl.com>; Mon, 18 Dec 2023 07:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level:
X-Spam-Status: No, score=-2.075 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ptb.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLG5he7Qg5-v for <ntp@ietfa.amsl.com>; Mon, 18 Dec 2023 07:20:52 -0800 (PST)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA340C14CEFC for <ntp@ietf.org>; Mon, 18 Dec 2023 07:19:58 -0800 (PST)
Received: from s23397.bs.ptb.de ([172.21.101.132]) by mx1.bs.ptb.de with ESMTP id 3BIFJdDn031314-3BIFJdDp031314 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Dec 2023 16:19:39 +0100
In-Reply-To: <CABrd9SSeQvpSY1JiJn3Nh9FsMFOo1Djk8nR9DoQ1EfRRdOyv7w@mail.gmail.com>
References: <20231217043500.99D6128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <OFD134C0BA.CC9AC877-ONC1258A89.0029CB64-C1258A89.002CCA3E@ptb.de> <CABrd9SSeQvpSY1JiJn3Nh9FsMFOo1Djk8nR9DoQ1EfRRdOyv7w@mail.gmail.com>
To: Ben Laurie <benl=40google.com@dmarc.ietf.org>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, Hal Murray <halmurray@sonic.net>, ntp@ietf.org
MIME-Version: 1.0
From: martin.langer@ptb.de
Message-ID: <OF60491801.92770502-ONC1258A89.005050E8-C1258A89.005431B9@ptb.de>
Date: Mon, 18 Dec 2023 16:19:37 +0100
Content-Type: multipart/alternative; boundary="=_alternative 005431B9C1258A89_="
X-FEAS-Client-IP: 172.21.101.132
X-FE-Policy-ID: 5:5:5:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=ptb.de; s=s1-ptbde; c=relaxed/relaxed; h=references:to:cc:mime-version:subject:from:message-id:date:content-type; bh=2q80nt42cPq2Dl/y9F54pj1M5Zum2RJYtEY1q2shYEI=; b=IbBHWI/1r6whXsgLSW6ZdxUTvhO+SCs/Ph8AasjFuosiRFcTPMTc7SktxUbYBPuJxVf0GCpz6CD/ 0DSXOW1grqKzFZUsuvDaaxtMJxkGKCnImw7P2XeIxNUXiLu62YFDKxvN6ABoRcFvKKaHLqCm630t JLdp8KgBmU1cqG+qLpEl5OTxqD/WJ30KyoTjlLrWQkWHVdhmCPqrQA3GWhGnpBtwUk6IA26vWsLR VpJHC3k/7NQdN6Tlgx8Wwbm/+wMRXXFVLy5lBNrEZ/v/7Vts6ZjAaPu3+B/RBpsMcT+15FSaAPFp e/2+Mxy2/q/OZqBLt88g7yoRTwNmpGpiikiTxA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/3Gsro7zXFipKAzX-2nlAM0gEJmw>
Subject: Re: [Ntp] Antwort: Why Roughtime?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2023 15:21:00 -0000
Hello all, But if I configure an NTS server in my client and the keys and certificates are valid, then I would expect the server not to intentionally send me false time information. ...and if I have multiple NTS-secured time servers, then the client can also protect itself against Byzantine errors. I'm still not really convinced by the server malfeasance mechanism. Is this really necessary for a "rough" time? What are the advantages over handling Byzantine errors or using something like NTP pools? In my humble opinion, Roughtime offers an advantage if I have weak hardware that doesn't or can't do TLS, so you just digitally sign the time information directly. I'd be happier if it didn't give the impression (as it does in some blogs and papers) that Roughtime solves the chicken-and-egg problem. I also want Roughtime to be minimalistic. ...why not just sign a Unix timestamp in seconds or max. milliseconds with EC or ED25519 and send it from the server to the client? ...or NTPv4 with an extension field containing a digital signature. ...something like that as a suggestion. but I may be seeing several things wrong. ...I'm always happy to be proven wrong. kind regards, Martin __________________________________________ Dr.-Ing. Martin Langer Physikalisch-Technische Bundesanstalt (PTB) Working Group 4.42 "Dissemination of Time" Bundesallee 100, 38116 Braunschweig (Germany) Tel.: +49 531 592-4470 E-Mail: martin.langer@ptb.de __________________________________________ Von: "Ben Laurie" <benl=40google.com@dmarc.ietf.org> An: kristof.teichel=40ptb.de@dmarc.ietf.org Kopie: "Hal Murray" <halmurray@sonic.net>, ntp@ietf.org Datum: 18.12.2023 15:11 Betreff: Re: [Ntp] Antwort: Why Roughtime? Gesendet von: "ntp" <ntp-bounces@ietf.org> On Mon, 18 Dec 2023 at 08:09, <kristof.teichel=40ptb.de@dmarc.ietf.org> wrote: 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 evidence. 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 E-Mail: kristof.teichel@ptb.de __________________________________________ -----"ntp" <ntp-bounces@ietf.org> schrieb: ----- An: ntp@ietf.org Von: "Hal Murray" <halmurray@sonic.net> Gesendet von: "ntp" <ntp-bounces@ietf.org> Datum: 17.12.2023 05:35 Kopie: "Hal Murray" <halmurray@sonic.net> 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@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp
- [Ntp] Why Roughtime? Hal Murray
- [Ntp] Antwort: Why Roughtime? kristof.teichel
- Re: [Ntp] Antwort: Why Roughtime? Ben Laurie
- Re: [Ntp] Antwort: Why Roughtime? martin.langer
- Re: [Ntp] Antwort: Why Roughtime? Ben Laurie
- [Ntp] Antwort: Re: Antwort: Why Roughtime? kristof.teichel
- [Ntp] Antwort: Re: Antwort: Why Roughtime? kristof.teichel
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Watson Ladd
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Daniel Franke
- Re: [Ntp] Antwort: Why Roughtime? Hal Murray
- Re: [Ntp] Antwort: Why Roughtime? Daniel Franke
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Hal Murray
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Hal Murray
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Daniel Franke
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Ben Laurie
- Re: [Ntp] Antwort: Why Roughtime? Ben Laurie
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? 黄振天
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? 黄振天
- Re: [Ntp] Antwort: Re: Antwort: Why Roughtime? Zhentian Huang
- Re: [Ntp] Antwort: Why Roughtime? wangshuai@mail.zgclab.edu.cn