[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.