Re: [Ntp] A simpler way to secure PTP

Daniel Franke <dfoxfranke@gmail.com> Mon, 10 May 2021 15:21 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 605F83A2090 for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 08:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, 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=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 6mQG9tEIIi6b for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 08:21:52 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 9D9E83A20A7 for <ntp@ietf.org>; Mon, 10 May 2021 08:21:52 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id t193so993979pgb.4 for <ntp@ietf.org>; Mon, 10 May 2021 08:21:52 -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; bh=ZrRSQxCpjxW5ZCW7hjV9A/cFnNs8cvJlQdgjZCZ6b9E=; b=f0A9pDGgrZtzCddHesWb+zTmQ6YuRFACQ2yEbg68ZdOIy7Nc6kxQuEDOx7FXxobnyj rW3v3sCF9/06jEGNkhUIJwvsIfo5oR13iU47GPGYVvVkgMitB04B1JVGqUImtIqIBucJ ZtdNGysC5TbtYkVaur4d9MdWmhw4ucZS1fRxRbWqSK1ISUTI3j2rg3OVjjoulUMyu67g bUbyV5+MCahe91BRV5VeDFely1TDDwPriCd6KJUh240gHdoXGb4nmtotwCbRzMcDH835 VRvt0u2fLAl93B71tO9v0MM9bWPtXomH6GI6f/XCS2Q/F0GoaRPRjaQ97K6QjbEQbWTy l/sQ==
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; bh=ZrRSQxCpjxW5ZCW7hjV9A/cFnNs8cvJlQdgjZCZ6b9E=; b=FUHclTyTJodkOHZYx7LtKDnYFUUvtiulWyMk39Z5koLmAHZ3Qe4ghMPynA2/p1j+9z n8nIluiaK73T0QGwyMmEyduPZVvTm113Dqgus71dmx9gcimTQiej4Kx1y2hazLRJX59n 8YGav6zPkalH110rAKDmF/hGKJ6BsvXOVBKmftIHUOo01T0fw5zz3gmlkeO12hFUzvgK y9QgnGyxrlxFDkFmYT4fzpoLmN/KoFhDjcuZhThjkOIwve3Sis9Nxuy0KcqQT74KWgr3 ZOzC+nrvTAbbQ2n2lmJoBTFbxfye65bBsWarFaFAlCRtXIk1f04Zc0Gy5kzghfCU3ge+ g1Pw==
X-Gm-Message-State: AOAM530R8VwWdFVYt+M38/WkyGiw9zOZTF5yFxaSS6J8Ed+cSiOL9zpn 23hRTnagyqOWGgyPtm1DJi2Do93Yl73HDMNHzYI=
X-Google-Smtp-Source: ABdhPJze9Rd7ZOrdOOPYHTSRHSeYETDgVQ06gAzuN8xiPT4K9RVJwTWEQcuT+gH9gPfr5t2pLEm9h/Jjs3R3lS8+a4Y=
X-Received: by 2002:a63:1921:: with SMTP id z33mr25956215pgl.211.1620660110957; Mon, 10 May 2021 08:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <YJkrFjnRPJJHz9da@localhost> <AM7PR02MB57657C935D0E94D223B1D703CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>
In-Reply-To: <AM7PR02MB57657C935D0E94D223B1D703CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Mon, 10 May 2021 11:21:39 -0400
Message-ID: <CAJm83bCRMJr4V59m97CUtOnF8Dbsg=pGPTD=n359imxUByJhVg@mail.gmail.com>
To: Doug Arnold <doug.arnold@meinberg-usa.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037218205c1fb5653"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/iKRYMhVAM82DuGTw2C3CAU6KtGM>
Subject: Re: [Ntp] A simpler way to secure PTP
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, 10 May 2021 15:21:58 -0000

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <doug.arnold@meinberg-usa.com>
wrote:

> I have heard of people actually doing this in the field as a sanity check.
>
>
>
> However, some applications that use PTP can be broken by introducing
> timing errors that are less than the expected difference between PTP and
> NTP.
>

You cannot solve this with cryptography. An adversarial network is, by
definition, one where you can't rely on statistical behavior and can't
neglect the probability of worst-case outcomes. The worst-case outcome for
any unicast protocol is going to be at least half the measured RTT, and for
a broadcast protocol the worst case is unbounded. As I've mentioned before,
you can improve this a little bit if you know a lower bound on the physical
distance `d` between the client and server, in which case you can shrink
each of your bounds by `d/c` where `c` is the speed of light, but this
still won't get you anywhere near the kind of precision you have in mind.
If worst-case, let alone typical-case, NTS4NTP behavior is going to break
your application in critical ways, then you MUST have a physically-secure
link to your time source. If you have an adversary on your communication
path, you're just screwed and cryptography can't save you.