[Ntp] Antw: Re: Follow-up to yesterday's mic comment about PTP security

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Thu, 25 July 2019 05:45 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 15D6B1204A3 for <ntp@ietfa.amsl.com>; Wed, 24 Jul 2019 22:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pdTUAaBr5lJg for <ntp@ietfa.amsl.com>; Wed, 24 Jul 2019 22:45:02 -0700 (PDT)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B20A12039C for <ntp@ietf.org>; Wed, 24 Jul 2019 22:45:02 -0700 (PDT)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 87FAA6000051 for <ntp@ietf.org>; Thu, 25 Jul 2019 07:44:59 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id 6C5CF6000050 for <ntp@ietf.org>; Thu, 25 Jul 2019 07:44:59 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 25 Jul 2019 07:44:59 +0200
Message-Id: <5D3941DA020000A100032624@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Thu, 25 Jul 2019 07:44:58 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "Daniel Franke" <dfoxfranke@gmail.com>,<kristof.teichel@ptb.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <CAJm83bD89oPE+WouWUD=qVqFzZ5-vw6E3RVsdVRteH0cEXyYjg@mail.gmail.com> <OFBC3F40BE.7ED6BF0D-ONC1258441.0023FF5E-C1258441.002675FE@ptb.de> <CAJm83bA74UiYbVbfYOHk4Vsw=go0d5P70uwbJ7CDvFrkdtcbfw@mail.gmail.com>
In-Reply-To: <CAJm83bA74UiYbVbfYOHk4Vsw=go0d5P70uwbJ7CDvFrkdtcbfw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/wt1MqWX_XC_zcDB9oYJnulLQsNI>
Subject: [Ntp] Antw: Re: Follow-up to yesterday's mic comment about PTP security
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: Thu, 25 Jul 2019 05:45:11 -0000

>>> Daniel Franke <dfoxfranke@gmail.com>; schrieb am 24.07.2019 um 16:09 in
Nachricht
<CAJm83bA74UiYbVbfYOHk4Vsw=go0d5P70uwbJ7CDvFrkdtcbfw@mail.gmail.com>;:
> On Wed, Jul 24, 2019 at 3:00 AM <kristof.teichel@ptb.de>; wrote:
>> 1.
>> It is established in general (and I have a proof lying around for a model
of 
> NTS in particular) that a client performing a request-response exchange with

> NTS and using all relevant checks gets a strong guarantee that the error in

> its measured offset is no larger than half the added flight times of the 
> packets (plus some negligibly small delta accounting for frequency 
> instability of the clocks used on client and server side).
>> For anyone wondering why we bothered to prove this again: this guarantee is

> 100%, and the new part is "no matter what a Man-in-the-Middle attacker did
in 
> the process".
> 
> The "half the RTT" error bound can be improved somewhat if you know
> the physical distance between yourself and the server. In which case

The probem is the "distance" here, as it definitely refers to "cable length",
or more specifically "route length". Back in the time when the WWW started,
connections inside Germany were routed via USA sometimes (that was the time
whan a "good" transferrate was near 5kB/s). To make matters worse, you cannot
safely assume that the route (length) from A to B will be the same as from B to
A.

> the error bound is ±(RTT/2 - distance / speed_of_light), because it is
> safe to assume that the network adversary does not have a wormhole
> through which to route your packets. (If you do have one, Akamai wants
> your resume).
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp