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

kristof.teichel@ptb.de Thu, 25 July 2019 07:05 UTC

Return-Path: <kristof.teichel@ptb.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 7D469120317 for <ntp@ietfa.amsl.com>; Thu, 25 Jul 2019 00:05:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 71XZ8aMBPGw8 for <ntp@ietfa.amsl.com>; Thu, 25 Jul 2019 00:05:47 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (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 0442D1202C6 for <ntp@ietf.org>; Thu, 25 Jul 2019 00:05:46 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id x6P75iD2026822-x6P75iD4026822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jul 2019 09:05:44 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 3603D815926; Thu, 25 Jul 2019 09:05:43 +0200 (CEST)
In-Reply-To: <b0672060-2d15-8339-22b2-c647480af9d6@nwtime.org>
References: <CAJm83bD89oPE+WouWUD=qVqFzZ5-vw6E3RVsdVRteH0cEXyYjg@mail.gmail.com> <OFBC3F40BE.7ED6BF0D-ONC1258441.0023FF5E-C1258441.002675FE@ptb.de> <CAJm83bA74UiYbVbfYOHk4Vsw=go0d5P70uwbJ7CDvFrkdtcbfw@mail.gmail.com> <5D3941DA020000A100032624@gwsmtp.uni-regensburg.de> <b0672060-2d15-8339-22b2-c647480af9d6@nwtime.org>
To: "Harlan Stenn" <stenn@nwtime.org>, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>, "Daniel Franke" <dfoxfranke@gmail.com>
Cc: ntp@ietf.org
MIME-Version: 1.0
Message-ID: <OF046B14CA.397A024F-ONC1258442.0026A9AB-C1258442.0026F91D@ptb.de>
From: kristof.teichel@ptb.de
Date: Thu, 25 Jul 2019 09:06:30 +0200
Content-Type: multipart/alternative; boundary="=_alternative 0026F91AC1258442_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/sJqNgDJXBi59arvZqBHYKMWUleI>
Subject: Re: [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 07:05:50 -0000

> >> 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.
> 
> A MITM can still do at least a delay attack.

None of that matters for what Daniel is saying.
A packet can still not have arrived *faster* than with lightspeed via the 
shortest line between the two devices.
And that's all you need to derive that the situation is in fact marginally 
better than "half of RTT (plus oscillator-related delta)".

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