Re: [Ntp] NTS pool support

Hal Murray <hmurray@megapathdsl.net> Sun, 21 July 2019 22:15 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 1ABE8120199 for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 15:15:08 -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 1ywT7hz-fenJ for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 15:15:07 -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 0E2211201D6 for <ntp@ietf.org>; Sun, 21 Jul 2019 15:15:06 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id ECA5C40605C; Sun, 21 Jul 2019 15:15:05 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Christer Weinigel <christer@weinigel.se>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Christer Weinigel <christer@weinigel.se> of "Sat, 20 Jul 2019 22:37:22 +0200." <3cd8c65b-a37c-863e-ea2c-2de0a5aeee96@weinigel.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 21 Jul 2019 15:15:05 -0700
Message-Id: <20190721221505.ECA5C40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pWFJKyaE_9jS9hKsJYt-QwyApow>
Subject: Re: [Ntp] NTS pool support
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: Sun, 21 Jul 2019 22:15:09 -0000

> Here's my naive suggestion on how to handle NTS pools.

I think you have to be very careful about what you mean by "pool".  In most 
NTP discussions, "the pool" usually means pool.ntp.org, a large collection of 
NTP servers run by volunteers.  Trust and secure don't make sense with that 
type of operation.  There is no point in using NTS.

Actually, I think we should NOT use NTS with "the pool".  It would give a 
false sense of security.

If the pool technology used with other pools?


Is there a term for a collection of NTP servers that are all run by the same organization?  I'll use "cluster".

Do we need pool technology if one organization runs the whole thing?  Why not just use separate names for each server?  How many servers will one organization want to run?  ...

One approach for clusters is for all the NTP servers to use the same certificate.  That means they all need the same secret key.  Cloudflare thinks that is reasonable.  They have lots of servers with the same certificate/key but use something other than pool technology to locate them.


We could avoid the key sharing by having the KE servers return the name on the certificate the server will use along with the IP Address.  That seems like a good idea.

For a more pool like approach, we need an option to return several batches of whatever is returned now - maybe with separate K2S and S2K for each batch.

---------

Or we could invent an alternate protocol.  The first stage just returns a list of names - what would have been in the SRV records.  The second stage does NTSKE with each name.  That's just reinventing SRV records in an environment we know is secure.

If we trust DNS we could use real DNS/SRV records.  I'm not a DNS wizard.  I don't know how to setup DNSSEC.  I'd be happy to use DNS/SRV if we find a DNS wizard who can point to a simple HOWTO type document that tells how to secure DNS.  We may need a separate document for each OS/distro.

What's the general status of DNSSEC these days?  Is it ready for prime time?  Should we be using it to help build critical mass?  Or using something else until more OSes/distros have good support?

Is there a simple/portable API to get SRV records?


-- 
These are my opinions.  I hate spam.