Re: [Ntp] Publication has been requested for draft-ietf-ntp-using-nts-for-ntp-20

Hal Murray <hmurray@megapathdsl.net> Thu, 14 November 2019 09:38 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 48E861208A1 for <ntp@ietfa.amsl.com>; Thu, 14 Nov 2019 01:38:55 -0800 (PST)
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 u4nE2Ht5-t5y for <ntp@ietfa.amsl.com>; Thu, 14 Nov 2019 01:38:54 -0800 (PST)
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 440C6120142 for <ntp@ietf.org>; Thu, 14 Nov 2019 01:38:53 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 2DF2D406063; Thu, 14 Nov 2019 01:38:53 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Miroslav Lichvar <mlichvar@redhat.com>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Miroslav Lichvar <mlichvar@redhat.com> of "Wed, 13 Nov 2019 17:07:10 +0100." <20191113160710.GD2634@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Nov 2019 01:38:53 -0800
Message-Id: <20191114093853.2DF2D406063@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Ig7MP1h_ccNObcALOqEIKsV6tck>
Subject: Re: [Ntp] Publication has been requested for draft-ietf-ntp-using-nts-for-ntp-20
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, 14 Nov 2019 09:38:55 -0000

mlichvar@redhat.com said:
>    with a list of one or more IP addresses to NTP servers for which the
> cookies

> Is it wrong to interpret a FQDN as a list of addresses? 

Good question.

I vote we add something like "use only one address, but the client gets to 
pick which one".

Our code processes the list in order, using the first one that isn't already 
in use.  Thus
  server foo.example.com nts
  server foo.example.com nts
Will get 2 connnections to the same server in the typical case where the 
server has both an IPv4 address and a IPv6 address.


Suppose we want to use more than one address.

Plan A would be to use all the addresses, starting each address with all 8 
cookies.  That would use the first 8 cookies multiple times and use the same 
C2S and S2C keys on multiple connections.  Hopefully, the crypto we are using 
will survive an attack using that info.  It seems appropriate not to push 
things unless we want to do a serious analysis.

Plan B would be to split the 8 cookies over several addresses.  That still 
leaves reusing C2S and S2C.  I think we have calculations on how much traffic 
a key is good for.  I didn't find anything with a quick scan of the draft.  
Did I miss it?  Should we add it?  Is a factor of 8 interesting?

Should we add a section about C2S and S2C lifetime, even if the result is off 
scale so we know how far off scale it is?


-- 
These are my opinions.  I hate spam.