Re: [Ntp] An NTPv5 design sketch

Miroslav Lichvar <mlichvar@redhat.com> Tue, 14 April 2020 11:25 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 694F83A0C5F for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 04:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 vCsAH6d67yGH for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 04:25:47 -0700 (PDT)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478253A0B71 for <ntp@ietf.org>; Tue, 14 Apr 2020 04:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586863546; 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=Gnj/+YSZIH/hMBiMJz+2ioYncE3NJlNHDkzfeKoccYQ=; b=ERCz0Uoz3iuIAn5refRXjYdzP932z9jRexauqPn66/Nhce3fmwKRoW2daqObHX7blb0yk2 AKKXW56ATdlo/EG/6VrbUq49sXyjtc1LCZeJ0mrsQkDW0Ao8wkNKH1UMzjOleLoAXWc+qf VueBThCHZVkXaXiT5bJs/5zwdgcBNr8=
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-26-SPHpIdLcML2WRo_sH6woMA-1; Tue, 14 Apr 2020 07:25:44 -0400
X-MC-Unique: SPHpIdLcML2WRo_sH6woMA-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 519C88017F5; Tue, 14 Apr 2020 11:25:43 +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 A16D29F999; Tue, 14 Apr 2020 11:25:42 +0000 (UTC)
Date: Tue, 14 Apr 2020 13:25:41 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
Message-ID: <20200414112541.GD1945@localhost>
References: <CAJm83bBV+Pox3r6KU49ShwMOvr=R+U_vDKJtSZhfT6XX4qWmbA@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAJm83bBV+Pox3r6KU49ShwMOvr=R+U_vDKJtSZhfT6XX4qWmbA@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/TcR--hTXF8d7ggEWMsftI-lGk6Q>
Subject: Re: [Ntp] An NTPv5 design sketch
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, 14 Apr 2020 11:25:48 -0000

On Sun, Apr 12, 2020 at 12:19:22PM -0400, Daniel Franke wrote:
> This is a sketch of a proposed NTPv5 design (by no means a complete
> spec, but hopefully good enough to make the concepts clear). It's a
> fairly ambitious step forward from previous versions, almost but not
> quite a green field design.  I say "almost" because it retains a
> couple limited backward-compatibility constraints:

Thanks for writing it down.

It's a bit too much for me to digest at once. I think I like the
general direction. I particularly like that it allows phase
adjustments to be separated from the base clock. I'm not sure about
TAI and PTP timestamps.

The main issue for me will probably be the dependency on NTS (and
TLS). I don't think that will work for many clients if NTPv5 is
supposed to replace NTPv4.

If I understand it correctly, the main advantage is that it makes
exploiting of follow-up messages more difficult. But it doesn't
prevent amplification attacks completely, right? An attacker who has
even a brief access to the victim's network, could capture a client
request asking for a follow-up message, or generate its own request,
and use this request for an attack until the server rotates the key
out.

-- 
Miroslav Lichvar