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

Miroslav Lichvar <mlichvar@redhat.com> Tue, 19 January 2021 11:10 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 9E82D3A1285 for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 03:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZmwSdKTy5dIp for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 03:10:58 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.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 F03AA3A1282 for <ntp@ietf.org>; Tue, 19 Jan 2021 03:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611054656; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IbnJf2d6njzwwjC3jj6wlsWlL0/xWGHkQ/YPsCtrgKM=; b=ZemN5Yt7YBQRT71iysxTyBSwLnRMXUz6HzwR/cm9NrxkZjhDuL7h/1NibxlfHL0dU/Pixs FrRrJdGxKcCREyFUfX6ElTknw9bar4h4dLUfUq1FvQay2zcJaJIxdXadGINNuUoW9VzGs/ psAN/AnWrL3l1CvIc/Z2Pfr6LqiTCLM=
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-251-rYexf61qPJKcv-wVvmeARA-1; Tue, 19 Jan 2021 06:10:55 -0500
X-MC-Unique: rYexf61qPJKcv-wVvmeARA-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 33E28800D55; Tue, 19 Jan 2021 11:10:54 +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 B2A6E60BF1; Tue, 19 Jan 2021 11:10:52 +0000 (UTC)
Date: Tue, 19 Jan 2021 12:10:51 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: FUSTE Emmanuel <emmanuel.fuste@thalesgroup.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <20210119111051.GC2430794@localhost>
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> <a17ebe20-8b8d-9685-433d-45f038ce6344@thalesgroup.com>
MIME-Version: 1.0
In-Reply-To: <a17ebe20-8b8d-9685-433d-45f038ce6344@thalesgroup.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
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="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ATsHe-Hj2P6jFndcbp3ElNxi4J4>
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 11:11:00 -0000

On Tue, Jan 19, 2021 at 10:20:31AM +0000, FUSTE Emmanuel wrote:
> Le 19/01/2021 à 10:42, Miroslav Lichvar a écrit :
> > 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.

It's not specific to the pool. IP addresses and domains are sold,
lost, hijacked, etc.

> And even in this case, you could cross enough sources to get better time 
> than most RTC ones.

Having multiple sources doesn't protect you against a focused MITM
attack.

> 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.

I'd say it's just shifting the responsibility. "Not my problem"
doesn't make that problem disappear.

If an attacker hijacks your domain and makes their own records, how
will your simple device know they shouldn't be trusted later when you
get it back? You will need to make some modification on the device.

When using NTS with your own servers, it might be easier to use a
self-signed certificate or your own CA. You can disable the time
validation, or make the certificate valid even in the initial boot
date (e.g. 1970). Of course, if the key is compromised, you will need
to update the device.

-- 
Miroslav Lichvar