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

FUSTE Emmanuel <emmanuel.fuste@thalesgroup.com> Tue, 19 January 2021 10:20 UTC

Return-Path: <emmanuel.fuste@thalesgroup.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 741B23A1412 for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 02:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 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, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thalesgroup.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 1ggRbktx_Imh for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 02:20:34 -0800 (PST)
Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (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 40C4C3A1408 for <ntp@ietf.org>; Tue, 19 Jan 2021 02:20:34 -0800 (PST)
Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4DKl68721Pz45LP for <ntp@ietf.org>; Tue, 19 Jan 2021 11:20:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thalesgroup.com; s=xrt20181201; t=1611051633; bh=O3UBPVeMDu9UNNzE+v8PW+iEXG5aDa2T8m1ZlAcqKMQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Transfer-Encoding:MIME-Version:From; b=L4gr6dUEkaRycEWmQWJoIqvL+l49Ew39wtvOaGsKUtwM/5pVGyx9eEhIaWwEUT8ng 6y7/h/RIr4MC+t9fMNrsG/BseNcfb7VdUkWCUyBg4b4Uu2xwp0fG5on3p/8LNJ7x8n YX1MwNxPbA4eurcPiKN6FQWd2I7xAqawENvDoHIi5+OgE/j3C/Eshu/9AQle+Xh0iV 6T0IyxA/Mz9H8V3jtbedEc6XvSHXYeHI5Mwx7KMkc6EVYB25ykaUJ3AeMJ3+aAhAW3 bdmDjq7sVUqK3wyToQ/vFFYsRna3oULbnvP6FJPr5v+Mv9Favhno7KF3y3zx5qSDrP Fu5uvGn6JuRrQ==
From: FUSTE Emmanuel <emmanuel.fuste@thalesgroup.com>
To: "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] NTP Security (was NTPv5: big picture)
Thread-Index: AQHW7Y5jCWcm9A+sZEOhE3CV1WddQKotdkMAgAAK4ICAAED4gIAAEC4AgAADnoCAAMz4gIAACqYA
Date: Tue, 19 Jan 2021 10:20:31 +0000
Message-ID: <a17ebe20-8b8d-9685-433d-45f038ce6344@thalesgroup.com>
References: <20210118113806.33BBE40605C@ip-64-139-1-69.sjc.megapath.net> <c6fda979-0b3e-99fc-2dc5-25b7cde4c42b@rubidium.se> <20210118162517.GA2410317@localhost> <acdd42d0-9b58-4b26-0798-55a42bc0b6de@rubidium.se> <YAX6gJiREb2RE6Gs@roeckx.be> <c5378682-e03f-9e46-24d5-025eb4a57c05@rubidium.se> <20210119094217.GB2430794@localhost>
In-Reply-To: <20210119094217.GB2430794@localhost>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
x-pmwin-version: 4.0.3, Antivirus-Engine: 3.79.0, Antivirus-Data: 5.81
Content-Type: text/plain; charset="utf-8"
Content-ID: <DD457F1D0BA1F74FA260F17CC1D94F97@iris.infra.thales>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pyFeR1aCwYx-aW6C4KE8ELB2R_Q>
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: Tue, 19 Jan 2021 10:20:37 -0000

Le 19/01/2021 à 10:42, Miroslav Lichvar a écrit :
> On Mon, Jan 18, 2021 at 10:28:41PM +0100, Magnus Danielson wrote:
>> On 2021-01-18 22:15, Kurt Roeckx wrote:
>>> In case keys are compromised, an attacker can send you an invalid
>>> initial time. That same attacker can create DNSSEC records, which
>>> you're happy to validate with the wrong time. So now you think DNS
>>> is working properly and ask for the time again, and still get the
>>> wrong time.
>> The DNSSEC records need to validate data-wise for the time-attack to do
>> any good. The design goal was just to enable the DNSSEC validation to
>> have good enough time for time-validation for bootstrap.
> I think the point is that you cannot bootstrap secure time out of
> nothing. You either do full validation using some trusted time source
> (e.g. RTC), or you don't. It doesn't matter if multiple systems are
> involved and their data seem consistent with each other.
I do not agree. Because :
>
> Even if we assume the attacker didn't manipulate the DNS(SEC) records,
> there is a possibility the name or address is no longer under the
> control of the original owner when those records were valid. In the
> pool that happens frequently.
This is a completely different and non technical problem, specific to 
the pool.
And even in this case, you could cross enough sources to get better time 
than most RTC ones.
When time matter, you will have RTC and other out of band validation 
process to ensure correct time.

The main point is that if I have a very simple device without RTC, which 
point to my own Internet NTP servers, I could bootstrap it with perfect 
confidence only by ensuring that the root DNS key are up to date. If I 
do not trust the root servers, this is another out of topic problem.

Emmanuel.