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

Kurt Roeckx <kurt@roeckx.be> Tue, 19 January 2021 17:48 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 A52723A0C94 for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 09:48:51 -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 H2Xa7_oBqXHa for <ntp@ietfa.amsl.com>; Tue, 19 Jan 2021 09:48:49 -0800 (PST)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 231173A0B2F for <ntp@ietf.org>; Tue, 19 Jan 2021 09:48:48 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id D27C9A8A0053; Tue, 19 Jan 2021 17:48:46 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 7429F1FE0E0F; Tue, 19 Jan 2021 18:48:46 +0100 (CET)
Date: Tue, 19 Jan 2021 18:48:45 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Magnus Danielson <magnus@rubidium.se>, ntp@ietf.org
Message-ID: <YAcbffNC0YA2IW7W@roeckx.be>
References: <acdd42d0-9b58-4b26-0798-55a42bc0b6de@rubidium.se> <YAX6gJiREb2RE6Gs@roeckx.be> <c5378682-e03f-9e46-24d5-025eb4a57c05@rubidium.se> <20210119094217.GB2430794@localhost> <68c0d807-2290-3c44-d760-35306af20434@rubidium.se> <20210119130408.GD2430794@localhost> <ed1de364-ab7c-86f4-2390-8d96ca708321@thalesgroup.com> <20210119135115.GF2430794@localhost> <ec32ae0b-e0bc-f337-4934-1518ff491879@rubidium.se> <20210119172624.GL2430794@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210119172624.GL2430794@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Fd2tebiLEFTaxoi36BQjhutEhhg>
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 17:48:52 -0000

On Tue, Jan 19, 2021 at 06:26:24PM +0100, Miroslav Lichvar wrote:
> On Tue, Jan 19, 2021 at 05:50:20PM +0100, Magnus Danielson wrote:
> > On 2021-01-19 14:51, Miroslav Lichvar wrote:
> > > The assumption is that both your DNSSEC and NTS was compromised at
> > > some point. You found out and rebuilt your infrastructure from
> > > scratch, but the attacker can still perform a MITM attack on your
> > > device if it doesn't know the current date in order to validate the
> > > certificate/records.
> > >
> > Outside of our scope. Way outside. We assume we can trust whatever these
> > mechanisms provide and our trust becomes tied to them. If you have ways
> > to attack that, this is not really the place to document those.
> 
> I don't agree. The mechanisms should be trusted only if used as
> intended, i.e. a full validation is performed. Skipping the time
> checks is a security risk. You seem to be saying that's ok, that you
> can combine outputs from two separate mechanisms using untrusted data
> and get a trusted output. I don't think that's the case. We can ask
> the DNS and CFRG groups.

I agree that you can't combine two things that are not validated
and end up with something that's validated. But everything really
is about probabilities and amount of work needed to break it. The
more keys that need to be compromised before you accept something
wrong, the more unlikely it is. I think it's really up to the
users to decide what is an acceptable risk.


Kurt