Re: [Ntp] NTPv5 draft

Philip Prindeville <philipp@redfish-solutions.com> Tue, 01 December 2020 00:19 UTC

Return-Path: <philipp@redfish-solutions.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 C2A213A126E for <ntp@ietfa.amsl.com>; Mon, 30 Nov 2020 16:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 B_As9ZBOcleo for <ntp@ietfa.amsl.com>; Mon, 30 Nov 2020 16:19:25 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (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 CD4143A1298 for <ntp@ietf.org>; Mon, 30 Nov 2020 16:19:25 -0800 (PST)
Received: from [192.168.3.4] (67-42-76-224.bois.qwest.net [67.42.76.224] (may be forged)) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 0B10JMfT077379 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Nov 2020 17:19:23 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <DCB6C97C-3CC3-4A75-B633-2A35E17573C3@akamai.com>
Date: Mon, 30 Nov 2020 17:19:22 -0700
Cc: Doug Arnold <doug.arnold@meinberg-usa.com>, Dieter Sibold <dsibold.ietf@gmail.com>, Miroslav Lichvar <mlichvar@redhat.com>, "ntp@ietf.org" <ntp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D83CF814-18DC-4DA8-88F8-BB7FFEAD7733@redfish-solutions.com>
References: <20201111161947.GG1559650@localhost> <AA848C67-CFB7-43FC-B190-FD3911360373@gmail.com> <49B3601E-C6A9-4B9E-BE9D-7FD69CCC54DC@meinberg-usa.com> <DCB6C97C-3CC3-4A75-B633-2A35E17573C3@akamai.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/WyO6OfcvDi5JBXORCtsFgCvgH_g>
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 00:19:27 -0000

> On Nov 30, 2020, at 4:44 PM, Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
> 
>>   I think that there is a possibility of a non safety-critical closed network application of ntp that does not need security.
> 
> I am strongly opposed to this for three and a half reasons:
> 1. The use-case is not known, so we should assume that NTPv4 is good enough.
> 1.5 If this is not the case, those who need this need to make the argument to this WG.
> 2. Security should no longer be optional for IETF protocols.
> 3. "Closed network" is increasingly unlikely; we're seeing more things "in the cloud" for example.
> 


Plus everything Rich said.

(2) in particular because there are so many things that might require accurate time that are potentially exploitable if this is defeated.

For instance, if I warp a clock sufficiently forward or backward, I can cause X.509 certificates to be outside of their validity windows, which could cause loadable kernel module (LKM) signature verification to fail, creating a denial-of-service of critical system services, protocol and device drivers, etc.  It could cause other trust-based (PKI) services like DNSSec to fail… Ssh… HTTPS… CRL’s themselves to be ignored (yeah, that’s a bit of a mind-twister, isn’t it?)…  secure firmware updates might fail, so exploitable vulnerabilities never get flushed out of the universe of IoT’s…