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

Magnus Danielson <magnus@rubidium.se> Mon, 18 January 2021 20:18 UTC

Return-Path: <magnus@rubidium.se>
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 43F1E3A00D2 for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 12:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level:
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, 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=rubidium.se
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 CCm0Qe7X7oxa for <ntp@ietfa.amsl.com>; Mon, 18 Jan 2021 12:17:57 -0800 (PST)
Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC123A00C9 for <ntp@ietf.org>; Mon, 18 Jan 2021 12:17:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id CC62B3F5D8; Mon, 18 Jan 2021 21:17:52 +0100 (CET)
Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (2048-bit key; unprotected) header.d=rubidium.se header.i=@rubidium.se header.b=Sb1ywvDp; dkim-atps=neutral
X-Virus-Scanned: Debian amavisd-new at bahnhof.se
Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-V3v-pbm5Nd; Mon, 18 Jan 2021 21:17:51 +0100 (CET)
Received: by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 2509A3F330; Mon, 18 Jan 2021 21:17:49 +0100 (CET)
Received: from machine.local (unknown [192.168.0.15]) by magda-gw (Postfix) with ESMTPSA id 81BDE9A0072; Mon, 18 Jan 2021 21:17:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rubidium.se; s=rubidium; t=1611001069; bh=01bf3flndWHKLPZHphXIDjpv2u/JXa1g7vo0uhx1X9k=; h=Cc:Subject:To:References:From:Date:In-Reply-To:From; b=Sb1ywvDpnmnkmbMsZxJIxnhZIZIG7BYBcgySePDKhJ4PIrt5r5wgmNtIYfTBv32JC Pv2PNL3pOYonk4OAlTGFyG5jJKhKduO1LabnsYd2pi6BsqOvbxm6i0v+KWO7NYmTkL ktTyCRfhrm4yHtvgEHaHNb6OpEQ30qIHHIZGNyaVWh7DfyOv5PAgJObaK/eagBnEij XN8DqFyDP9bruEfL/4h4WVaWQP/Y2tWmEYN9Ld2g0ByLgVLGQYGIS5JWGOTDEw+hRe NM6s5H+R/mSqrJutA341Fa6HtURnL7Bxo2O6Q6h4Ffu7wnEMu4sKTBW+UZyixrc3rm y4W7ziqEoGLHw==
Cc: magnus@rubidium.se, ntp@ietf.org
To: Miroslav Lichvar <mlichvar@redhat.com>
References: <20210118113806.33BBE40605C@ip-64-139-1-69.sjc.megapath.net> <c6fda979-0b3e-99fc-2dc5-25b7cde4c42b@rubidium.se> <20210118162517.GA2410317@localhost>
From: Magnus Danielson <magnus@rubidium.se>
Message-ID: <acdd42d0-9b58-4b26-0798-55a42bc0b6de@rubidium.se>
Date: Mon, 18 Jan 2021 21:17:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <20210118162517.GA2410317@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/LORwlBXAtbbFv6scHpNOOBvOSWg>
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 20:18:01 -0000

Hi,

On 2021-01-18 17:25, Miroslav Lichvar wrote:
> On Mon, Jan 18, 2021 at 04:46:22PM +0100, Magnus Danielson wrote:
>> 6) If verified time matches that of the initial handshake request (as
>> updated using local time progess), then unauthenticated time in step 2
>> and 3 was valid, and thus the verification was valid and progress, else
>> fail.
>>
>> So, we see how unauthenticated time can be used to bootstrap the
>> handshake. Notice that this is not used to initiate node time, but only
>> for that handshake. Only after things is secured, you accept time as
>> being secured.
> I don't quite follow. If A was compromised at some point, how do you
> know you are not talking to the attacker intercepting your requests
> and giving you old signatures? Isn't the whole point of the validity
> period to prevent such attacks? If you don't know the current time,
> how can you validate anything that's not supposed to be trusted
> forever?
>
You actually do not trust the time you get initially. You validate it.
If your DNSSEC is invalid because of time, then the DNSSEC does not
validate. If your DNSSEC is invalid because false data, the DNSSEC does
not validate. Then, if and only if DNSSEC validate, only then you get
time but using the data-validated path, and only then you validate if
the original time and the validated time match up. If they don't, then
you do not trust either. If you can spoof the DNSSEC to validate, you
are toast anyway, if you have put your trust there.

Now, one *could* argue that the validated time from A can be trusted
even if the non-validated initial time mismatch. This could be used for
relaxed rules, but should result in warning.

If someone feeds you DNS-records that is wrong, DNSSEC should not validate.

If someone feeds you initial non-validated time that is wrong, that is
caught later. It may be "good enough" for the DNSSEC to be valid, but we
do not trust that value any further, it's only used in the boot-strap
procedure to hand-off to the secured form.

Cheers,
Magnus