Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt

Hal Murray <hmurray@megapathdsl.net> Mon, 22 April 2019 08:06 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 295CE1200DB for <ntp@ietfa.amsl.com>; Mon, 22 Apr 2019 01:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.033
X-Spam-Level: *
X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982] 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 GeDX-mA6V5U8 for <ntp@ietfa.amsl.com>; Mon, 22 Apr 2019 01:06:21 -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 368F1120114 for <ntp@ietf.org>; Mon, 22 Apr 2019 01:06:21 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 6323340605C; Mon, 22 Apr 2019 01:06:20 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: ntp@ietf.org
cc: hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from internet-drafts@ietf.org of "Wed, 17 Apr 2019 01:14:38 PDT." <155548887861.29104.9877701109792066850@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Apr 2019 01:06:20 -0700
Message-Id: <20190422080620.6323340605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/_YTkU-81lLjnB2_4viiQqotjDJc>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt
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: Mon, 22 Apr 2019 08:06:22 -0000

Typo, page 20:
  Duplicate "Nonetheless, "

Page 6, single round trip
  That's after the TLS setup.  Right?  How many round trips does that take?

Page 13: cookies
  Do all cookies have to have the same length?

Page 17, Nonce length and Nonce in general.
  I don't understand this area.  (My version of "understand" is that I could 
explain it to somebody.)

  It seems really really ugly to have an Additional Padding field that 
requires a layer of magic to compute the length.  Am I missing something 
simple?

  If I poke around in AEAD RFCs, I find text about having a counter to make 
sure the nonce is unique.  Is that appropriate or necessary?  It's really 
really hard to keep from reusing a counter if you consider disks getting 
restored from backup and such.

  Are random number generators good enough?  How do I figure out how many bits 
I need?

  How nonce-reuse resistant are the algorithms we are using?

Why not require the client to use the same length as the server?  Maybe pad 
the client nonce with 0s if generating randomness is expensive and it doesn't 
need as long a nonce as the server.

Did anybody test this?  (I doubt if our code will do the right thing.)

Should we include a table of AEAD algorithms and the Nonce size?

Page 19:
  Why MUST the Unique Identifier be in the clear?

Page 21:
  What is  an AEAD tag?  I couldn't find any other references.

Page 23:  KoD/NTSN
  They can be forged.  What's the current policy on processing KoDs?

Page 23, last paragraph, save AEAD alg, S2C, C2S, and cookie to avoid NTS-KE 
on NTP restart.
  I think that paragraph would be better in an appendix.
  In addition to avoiding the load on the NTS-KE server, it also avoids the 
time delay that would add to the startup sequence.

Page 24:  "AEAD key"
  AEAD is used in two contexts - one for the wire and another for cookies.  It 
would be nice if that word wasn't reused here.  I don't have any good 
wordsmith suggestions.


Page 36, checking certificates before you know the time.

  Does the NTP_PHASE_MAX test work with systems that have been sleeping in low 
power mode?

  "by picking a random time in the week preceding"...
  At a quick read, it's not obvious if that's an example of what to do or what 
not to do.  Is the idea that the certificate will get updated at least a week 
in advance, so asking a week in advance will get the new certificate?

Page 37/42, [Shpiner]
  The reference on page 42 says "Mizraha, T" - no mention of Shpiner.


-- 
These are my opinions.  I hate spam.