Re: [Ntp] NTPv5 draft

Kurt Roeckx <kurt@roeckx.be> Tue, 01 December 2020 08:50 UTC

Return-Path: <kurt@roeckx.be>
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 A779B3A0D08 for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 00:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 h79lt2-v9v_8 for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 00:50:57 -0800 (PST)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a05:7300:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B953A0D1C for <ntp@ietf.org>; Tue, 1 Dec 2020 00:50:57 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 1B407A8A0EDF; Tue, 1 Dec 2020 08:50:52 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D14161FE0DDE; Tue, 1 Dec 2020 09:50:51 +0100 (CET)
Date: Tue, 01 Dec 2020 09:50:51 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Dieter Sibold <dsibold.ietf@gmail.com>, ntp@ietf.org
Message-ID: <20201201085051.GL971977@roeckx.be>
References: <20201111161947.GG1559650@localhost> <AA848C67-CFB7-43FC-B190-FD3911360373@gmail.com> <20201201081203.GB1900232@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20201201081203.GB1900232@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0WiPu3c8X517kQcMQilofp5Kp_w>
Subject: Re: [Ntp] NTPv5 draft
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: Tue, 01 Dec 2020 08:51:00 -0000

On Tue, Dec 01, 2020 at 09:12:03AM +0100, Miroslav Lichvar wrote:
> > I very much agree with Jame’s proposed draft that a new
> > version of NTP must provide these mechanisms by default.  Sure, you can add
> > NTS to protect the NTPv5 packets. But in this case protection is always an
> > optional add-on whereas it needs to be an inherent part of the basic
> > protocol. To achieve this the NTS approach certainly can be transferred to
> > the basic v5 protocol and packet format.
> 
> You mean to require all NTP packets to be authenticated? I don't like
> that idea. The improvements in NTPv5 are orthogonal to authentication.
> NTPv5 is not supposed to be more secure. An NTP client that doesn't
> want to implement the complexity of NTS shouldn't be restricted to
> NTPv4.

As far as I know, it's currently still not possible to use NTS
with the pool, so we can't always use the authentication.

If devices like switches can be involved in the protocol too, do
we also want their data to be authenticated?


Kurt