Re: [Ntp] NTP Security (was NTPv5: big picture)

Miroslav Lichvar <mlichvar@redhat.com> Mon, 18 January 2021 10:12 UTC

Return-Path: <mlichvar@redhat.com>
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 D0F603A11EE for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 02:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 uBDN1kB9pabX for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 02:12:56 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127A53A11EB for <ntp@ietf.org>; Mon, 18 Jan 2021 02:12:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610964775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OApxB2VvLdyyMBVngq5fN9xfAPWwAyzyLE/jFOz9HPI=; b=Hp2soJRtjnsC5yoKtuFGAkazVs1h1/aXmnaOfcK8GOHeiPZKwyeq1bNcjoFciuEsc5KrZs VlSel+6YEf74OhLqISXSC8oMHTQEkiYfhP72c0MxA42Q9jIs2Cqqj/bjozm5mU7j+Wwer0 gL8d96uVxVTLS3TddARk218jaR9f0GM=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-544-VfM1C3I3Nni9CHlxz5nLiw-1; Mon, 18 Jan 2021 05:12:52 -0500
X-MC-Unique: VfM1C3I3Nni9CHlxz5nLiw-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7321E192D78E; Mon, 18 Jan 2021 10:12:51 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 24B425B699; Mon, 18 Jan 2021 10:12:49 +0000 (UTC)
Date: Mon, 18 Jan 2021 11:12:48 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Kurt Roeckx <kurt@roeckx.be>, James Browning <jamesb.fe80@gmail.com>, NTP WG <ntp@ietf.org>
Message-ID: <20210118101248.GA2381354@localhost>
References: <rsalz@akamai.com> <993FEEB5-F498-472E-813E-E684E273612F@akamai.com> <20210102050501.7D0DE40605C@ip-64-139-1-69.sjc.megapath.net> <26A97601-BEB4-4914-B570-6C8BD9C72FAD@akamai.com> <CACsn0cm=d3z+ceTDMaw2LDHg_AeNoxbs411iEFNpGpnWcyvZvw@mail.gmail.com> <CAFTY+dAMNZF_qPbzo2Fsj1LtF5+s-cze5s52rxBZSk6ofzG9gQ@mail.gmail.com> <YAN4PSgwEOVYkAJF@roeckx.be> <CACsn0cmhJhhM4Ab64RXRknRi+jM-SugFYvA+71tSV4c0XXmAgQ@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CACsn0cmhJhhM4Ab64RXRknRi+jM-SugFYvA+71tSV4c0XXmAgQ@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/SXW4c8BLS6kF6JvhE84nONvmbrw>
Subject: Re: [Ntp] NTP Security (was NTPv5: big picture)
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, 18 Jan 2021 10:12:58 -0000

On Sat, Jan 16, 2021 at 04:43:21PM -0800, Watson Ladd wrote:
> On Sat, Jan 16, 2021 at 3:35 PM Kurt Roeckx <kurt@roeckx.be> wrote:
> > On Sat, Jan 16, 2021 at 02:49:33PM -0800, James Browning wrote:
> > > 2) Have the pool run a common NTS-KE server for all NTS servers in the pool.
> >
> > As far as I understand things, that would not be a good idea.
> 
> Agreed. The key management and synchronization in such a system is a pain.

Also, format and content of cookies is implementation-specific, so
that NTS-KE server would need to specifically support all common
implementations.

I suspect a bigger issue would be the resources required for the
NTS-KE service. I don't think it's likely it would be able to run on
the core pool's infrastructure. (One of the main points of the pool is
to share the costs.)

> > > 3) Convince TLS certificate vendors to sell IP based certificates.

IIRC, ZeroSSL (one of the LetsEncrypt alternatives) can issue
certificates for IP addresses. But I'm not sure if availability of
such certificates changes anything. The clients of the pool would
still need to get the addresses in a secured way.

> > Open a TLS connection to ask for servers, get a list of hostnames.
> 
> This has some interesting advantages.

And it shares the scalability issue with the common NTS-KE server. I
think the load needs to be shared among the volunteers' servers.

-- 
Miroslav Lichvar