[Ntp] NTS draft - nits

Hal Murray <hmurray@megapathdsl.net> Thu, 19 March 2020 19:39 UTC

Return-Path: <hmurray@megapathdsl.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 021253A0E0D for <ntp@ietfa.amsl.com>; Thu, 19 Mar 2020 12:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.035
X-Spam-Level: *
X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYPjFt6kCnvj for <ntp@ietfa.amsl.com>; Thu, 19 Mar 2020 12:39:12 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 662163A0E0A for <ntp@ietf.org>; Thu, 19 Mar 2020 12:39:12 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id CBD8440605C; Thu, 19 Mar 2020 12:39:11 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: ntp@ietf.org
cc: Hal Murray <hmurray@megapathdsl.net>
From: Hal Murray <hmurray@megapathdsl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Mar 2020 12:39:11 -0700
Message-Id: <20200319193911.CBD8440605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/qL9aHl69sFyHLGHqQxEnNjvKcyA>
Subject: [Ntp] NTS draft - nits
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Thu, 19 Mar 2020 19:39:14 -0000

Nits.  Not worth a new version just for these, but if you are editing for some 
other reason, please consider ...

------------

I can't find any place where the draft explicitly says that NTS doesn't 
guarantee anything about the quality of the time you get.  I'm concerned that 
the "good" as applied to security will get transferred to time.  I suggest a 
sentence in both the Introduction and Security Considerations.  Something like:

NTS doesn't say anything about the accuracy of the time you will get, only 
that the response, if any, came from the server you expect to be talking to.

------------

NTP_PHASE_MAX

>From 9.4. Initial Verification of Server Certificates

  Check whether the system time is in fact unreliable. If the
  system clock has previously been synchronized since last boot,
  then on operating systems which implement a kernel-based phase-
  locked-loop API, a call to ntp_gettime() should show a maximum
  error less than NTP_PHASE_MAX. In this case, the clock SHOULD be
  considered reliable and certificates can be strictly validated.

I can't find a good reference for NTP_PHASE_MAX
It's not in RFC 5905
It's not in the kernel sources or /usr/include/ on Linux, FreeBSD, or NetBSD.

It is in the Linux man page for ntp_gettime
       maxerror
              Maximum error, in microseconds.  This value can  be  initialized
              by ntp_adjtime(3), and is increased periodically (on Linux: each
              second), but is clamped to an upper limit (the  kernel  constant
              NTP_PHASE_MAX, with a value of 16,000).

Google finds that man page (several translations) and the NTS draft.

I think that only works if relatively smart code set the time.  If the 
operator set the time from his watch there probably isn't any error estimate.


-- 
These are my opinions.  I hate spam.