Re: [Ntp] An NTPv5 design sketch

Daniel Franke <dfoxfranke@gmail.com> Tue, 14 April 2020 14:35 UTC

Return-Path: <dfoxfranke@gmail.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 DD0F83A0831 for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 07:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 17eVgOeKmvXL for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 07:35:28 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A0C3A082C for <ntp@ietf.org>; Tue, 14 Apr 2020 07:35:28 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id h6so13382016iok.11 for <ntp@ietf.org>; Tue, 14 Apr 2020 07:35:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u5L+HNgxL/deGhxSbmkkNR+XAvF0Ubvklbt6htaPQvg=; b=XQ4vCUWAISMFHfBrinowuzr3lgSscKTZZCzB2t9QNaTMIX86PZezoOfNINxms84HFz 0+g2S+Z/UmvyFitTQY6zRrfmbkvZji9c7Y627d5xnBM3kx0D5k/nPc52Q+aDTKDsvMVA GsHkZfpgbP1yLK4JSHhx6swIjQyjCJu/7ujSFb/ihCudxXBH54j0aU48pUdRKyDln2Nl 718K5j3Ji+LfZJ8zXloH1TusOlcl+pXh4l++Frn8Q7UM+VZnniRn6I/xwFQJC0dAon0S nvTkzAtGH39NMeV1ljTbtQRr+8YxM6bp6uPvnwmPAATIkBTAIso8pUm5yL3pVWYYOk/G n01w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u5L+HNgxL/deGhxSbmkkNR+XAvF0Ubvklbt6htaPQvg=; b=c9mg4GP4X2Yr7Cn8B8bAGMUJ6SDIzkNQWss6t/JQ6QvwrqCBhs1ocbLXqE3/WnN/S8 6fy4BlJq29LjATpm8cziX/zZwkDoFfb7tdsjgrtJ2MjsFDISMQ2I4LJoCAVUPrwjPmw+ T/qKDYSwThuO/noaNRnYiwxnUANFwqNgWa7w6iFU3VSubGq/B3Beg6Pvd+wMVf/BaD2B J1FZKuPl8VrlGxu3okuSvlU+kHA9xD60lnMCxVnKZw0gRPhmxQ6v1zgOFYAYTJpGj1dj dCNSS+1OPqAoqRL1Se92NPuWkkDGeY2rMm9Ft8xq9FATG6qDlhN+wfX2d0upjaIdEQfr iAhw==
X-Gm-Message-State: AGi0Pub4/tGHz46CEkQOs4oiWpR8D6aQR4NhSnRPQLD4VoQ8D4xyVVhb zbJWwpzg0qsCXGBFPo5fRuZ7hqnMYa3A2pWg0yAepkrW
X-Google-Smtp-Source: APiQypKmVArGDUb5Z4EkORvMI7raqRcDf7OqxITgO2vtUHibLGvADsRIN7lEWYMTavLwekOUmFvuhF8gHkW7U06ml1s=
X-Received: by 2002:a02:2b11:: with SMTP id h17mr20101821jaa.140.1586874927905; Tue, 14 Apr 2020 07:35:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAJm83bBV+Pox3r6KU49ShwMOvr=R+U_vDKJtSZhfT6XX4qWmbA@mail.gmail.com> <20200414112541.GD1945@localhost>
In-Reply-To: <20200414112541.GD1945@localhost>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Tue, 14 Apr 2020 10:35:16 -0400
Message-ID: <CAJm83bAFwZYtWac-ABL-ozMqa=oppekF078-zOBmMUD7=Ah=Bw@mail.gmail.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: NTP WG <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/3fQh5_W0NITskombzpcnGE0G8Bs>
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 14:35:34 -0000

On Tue, Apr 14, 2020 at 7:25 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:

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

NTS and the scheme for preventing abuse of follow-up messages aren't
particularly closely connected. The NTS cookie provides a convenient
place to hang the network address binding, but if it weren't already
there it would be easy to add a protocol message to acquire it,
following a similar pattern to DTLS's HelloVerifyRequest.

You're correct — having just a brief ability to receive traffic at a
particular IP address allows later amplification of traffic to that
address until the cookie expires. But the same thing is true of
practically every other protocol on the internet. Modern UDP-based
protocols like QUIC implement a similar scheme to this one, with the
same shortcoming and a much larger amplification factor. Anything
TCP-based is susceptible as well, if the attacker can learn (or guess)
the initial SYN value. Basically, I think we're already going
above-and-beyond in terms of anti-amplification measures and such a
very weak attack, with not even a factor-of-2 amplification if it
succeeds, is not one we need to worry about any further.