Re: [Ntp] A simpler way to secure PTP

Daniel Franke <> Mon, 10 May 2021 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 605F83A2090 for <>; Mon, 10 May 2021 08:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6mQG9tEIIi6b for <>; Mon, 10 May 2021 08:21:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D9E83A20A7 for <>; Mon, 10 May 2021 08:21:52 -0700 (PDT)
Received: by with SMTP id t193so993979pgb.4 for <>; Mon, 10 May 2021 08:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <YJkrFjnRPJJHz9da@localhost> <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Mon, 10 May 2021 11:21:39 -0400
Message-ID: <>
To: Doug Arnold <>
Cc: Miroslav Lichvar <>, NTP WG <>
Content-Type: multipart/alternative; boundary="00000000000037218205c1fb5653"
Archived-At: <>
Subject: Re: [Ntp] A simpler way to secure PTP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 15:21:58 -0000

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <>

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