[Ntp] Comments on Roughtime
Hal Murray <halmurray@sonic.net> Sun, 14 August 2022 04:33 UTC
Return-Path: <halmurray@sonic.net>
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 D02D9C1522C0 for <ntp@ietfa.amsl.com>; Sat, 13 Aug 2022 21:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 J4XptLFVpGvx for <ntp@ietfa.amsl.com>; Sat, 13 Aug 2022 21:33:02 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1BAC1522C2 for <ntp@ietf.org>; Sat, 13 Aug 2022 21:33:02 -0700 (PDT)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (107-137-68-211.lightspeed.sntcca.sbcglobal.net [107.137.68.211]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 27E4X0Fa029227 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 13 Aug 2022 21:33:01 -0700
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 76D0128C1EF; Sat, 13 Aug 2022 21:33:00 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1
To: ntp@ietf.org
cc: Hal Murray <halmurray@sonic.net>
From: Hal Murray <halmurray@sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 13 Aug 2022 21:33:00 -0700
Message-Id: <20220814043300.76D0128C1EF@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVZOjBHWsVlrSrPTyxJKGZUVWC75N6g9lctVZbaoXaBQLNaTEgfnamRGXfB9DgH/F0EHG8/I8y67TNXT8WNbQvquSzJ/P30lavo=
X-Sonic-ID: C;Lu/jLYob7RGididyR+6Zsg== M;fvYOLoob7RGididyR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/nf4HgayxUCx3xskVFMa_IiTWSeI>
Subject: [Ntp] Comments on 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: Sun, 14 Aug 2022 04:33:06 -0000
Section 5.1.1 int32 You are using signed-magnitude when int32 is widely used to mean 2s complement. It doesn't even say "sign-magnitude until the second sentence. I suggest switching to 2s complement. If you don't want to change the bits on the wire, split it into a flag and an uint31. Sections 5.1.1, 5.1.2, 5.1.3: int32, uint32, uint64 All are "least significant byte first". That's little endian. The IETF is traditionally big endian. I don't know if you can get that past the appropriate reviewers. If you can, it needs some SHOUTING TEXT warning of the non-standard usage. Section 6.2.5 SREP Servers MUST ensure that the true time is within (MIDP-RADI, MIDP+RADI) at the time they transmit the response message. This gets into an interesting can of worms. What does MUST mean in this context? I picture clock errors as having long tails. How many 9s to you want? What's the right way to think about this? Section 6.2.5, last sentence ... server does not hold any updated leap second information. Why the updated? I think it makes sense if you remove it. Section 12 Security Considerations, second paragraph. Maintaining a list of trusted servers and adjudicating violations of the rules by servers is not discussed in this document and is essential for security. Roughtime clients MUST regularly update their view of which servers are trustworthy in order to benefit from the detection of misbehavior. That conflicts with solving my 10 year problem. (My 10 year problem is a spare that sits on the shelf for 10 years. That box won't have a RTC so it won't know the time when first plugged in. Traditional certificates will have expired...) There are 2 types of misbehavior: bugs and evil. I didn't find any discussion of how many servers to use. With 3 servers, 2 can outvote 1 bad guy. ... I think the same logic applies to NTP servers and Roughtime servers. Chronos may get tangled up here. Maybe we should start another thread. Part of the discussion would be how old is your list of trusted servers. I didn't look at any of the Merkle text. -- These are my opinions. I hate spam.
- [Ntp] Comments on Roughtime Hal Murray
- Re: [Ntp] Comments on Roughtime kristof.teichel