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

Kurt Roeckx <kurt@roeckx.be> Mon, 18 January 2021 12:23 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 9B1703A12C4 for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 04:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 8RAsY-vaL_c4 for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 04:23:11 -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 C04883A12C6 for <ntp@ietf.org>; Mon, 18 Jan 2021 04:23:11 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 1A698A8A006C; Mon, 18 Jan 2021 12:23:08 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id B075E1FE0E0B; Mon, 18 Jan 2021 13:23:07 +0100 (CET)
Date: Mon, 18 Jan 2021 13:23:07 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: FUSTE Emmanuel <emmanuel.fuste@thalesgroup.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YAV9q3k3NoJ2Mt38@roeckx.be>
References: <20210118113806.33BBE40605C@ip-64-139-1-69.sjc.megapath.net> <629b80fb-1fd7-842b-140a-d2fb08117e9b@thalesgroup.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <629b80fb-1fd7-842b-140a-d2fb08117e9b@thalesgroup.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/5PtVZPrBSiG4yAXXiZfAYMUnS_I>
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 12:23:15 -0000

On Mon, Jan 18, 2021 at 12:02:04PM +0000, FUSTE Emmanuel wrote:
> Le 18/01/2021 à 12:38, Hal Murray a écrit :
> > emmanuel.fuste@thalesgroup.com said:
> >> And all bootstrapping problems could be solved with CD / DO flags  controls
> >> and validation back checking with the first returned time of day.
> > How is that back checking going to work?  You don't know the time yet.
> >
> > Sure, it will say "OK" if you are talking to an honest server, but if you are talking to a bad guy, it can lie consistently.  Am I missing something?
> DNSSEC and/or DANE validation will fail if it is really a "bad guy" eg 
> it is not really the guy you tried to connect to, even if the given time 
> is "good" for DNS resolutions.
> For long time on the shelf, you will have to update the root DNS key if 
> the device is operating on the Internet, but only that.
> 
> For standard X509 model, you will have to update the certificate 
> authority list/public key anyway.

There aren't really much differences between X509 and DNSSEC.

> And if we talk about security, DNSSEC 
> validation capability is something that should be mandatory for any 
> device that is connected to the Internet today.

See:
https://blog.apnic.net/2020/03/02/dnssec-validation-revisited/
https://stats.labs.apnic.net/dnssec/

We're at about 25% that's currently validating, and 10% that has
both a validating and non-validating resolver.

Software can use a library to do the validation itself rather than
rely on resolver to do it.


Kurt