Re: [Ntp] Follow-up to yesterday's mic comment about PTP security
kristof.teichel@ptb.de Wed, 24 July 2019 07:00 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 A1C191202DF for <ntp@ietfa.amsl.com>; Wed, 24 Jul 2019 00:00:12 -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 5x1-E-ucsvMd for <ntp@ietfa.amsl.com>; Wed, 24 Jul 2019 00:00:10 -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 C0F31120332 for <ntp@ietf.org>; Wed, 24 Jul 2019 00:00:09 -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 x6O707PN008752-x6O707PP008752 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Jul 2019 09:00:07 +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 19DD58144E0; Wed, 24 Jul 2019 09:00:07 +0200 (CEST)
In-Reply-To: <CAJm83bD89oPE+WouWUD=qVqFzZ5-vw6E3RVsdVRteH0cEXyYjg@mail.gmail.com>
References: <CAJm83bD89oPE+WouWUD=qVqFzZ5-vw6E3RVsdVRteH0cEXyYjg@mail.gmail.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
MIME-Version: 1.0
Message-ID: <OFBC3F40BE.7ED6BF0D-ONC1258441.0023FF5E-C1258441.002675FE@ptb.de>
From: kristof.teichel@ptb.de
Date: Wed, 24 Jul 2019 09:00:54 +0200
Content-Type: multipart/alternative; boundary="=_alternative 002675FCC1258441_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/06Zn4W-oODBRjZpwV2NmrV3JJzI>
Subject: Re: [Ntp] 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: Wed, 24 Jul 2019 07:00:13 -0000
Hey all, first of all, I'm really glad if this whole thing (security of one-way mechanisms and mechanism selection) is a discussion that we're going to have in the WG. To comment on your assertions, Daniel: 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". So I would be careful about naming a specific amount, because flight times do depend on the specific client's connection - but 50ms seems like a good rule of thumb, and I overall agree with your assertion. 2.-3. If we're operating und the assumptions that a) you can only use one time sync mechanism at a time and keep track of one clock disciplined via data from that mechansim, and b) end users always have exactly one requirement level for each of security and precision/accuracy and need to use the least-effort path to achieve them ... then I agree with your assertions whole-heartedly. But I really think both assumptions deserve their own hard looks and considerations. For example, it might be reasonable for someone, specifically a financial institute, to run NTP with NTS in their local network to obtain a 100% security guarantee for a 100us level (demanded by MiFID II for example) and also still use PTP / White Rabbit (unsecured for the time being) to have the precision/accuracy levels they actually want - with no strong guarantee, but still valid in the (most likely) case that their infrastructures are not currently under attack. 4. Again, I agree with the assertion for the most part and in the given status quo. But the underlying assumption that every relevant adversarial 2-way network also suffers from long, unpredictable and asymmetric travel times is mostly valid because the only candidate for such a network is the internet. If someone built, say, a GNSS network where two-way communication (with satellites or between two ground stations) was readily available to everyone, the whole situation would be different: That would still potentially qualify as an adversarial network, but with the proper crypto, your 100% security guarantees could be extended to much better precision/accuracy levels. The same thing could be true for long-distance tree-topology fibre-based networks exclusively for time synchronization - which are kind of in the process of being built all over Europe. Lengthy comments and caveats notwithstanding, I agree with and would endorse your 1.-4. decision making sheet as an excellent starting point. Best regards, Kristof "ntp" <ntp-bounces@ietf.org> schrieb am 23.07.2019 18:19:33: > Von: "Daniel Franke" <dfoxfranke@gmail.com> > An: "NTP WG" <ntp@ietf.org> > Datum: 23.07.2019 18:20 > Betreff: [Ntp] Follow-up to yesterday's mic comment about PTP security > Gesendet von: "ntp" <ntp-bounces@ietf.org> > > My comments yesterday about PTP security shifted context a few times > so it may have been hard to follow what I was claiming. My assertions > were: > > 1. If you need 50ms precision, pick some good public NTP servers and use NTS. > > 2. If you need 100µs precision, colocate a time source in the same > datacenter as the client systems. Use NTP and NTS; you don't need PTP > for this. > > 3. If you need 1µs precision, use PTP and physically secure the link > between the time source and the clients so that cryptographic > authentication is unnecessary. > > 4. If you need 1µs precision over an adversarial network, good luck! > This is simply not achievable and no amount of cryptographic pixie > dust is ever going to save you. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp
- [Ntp] Follow-up to yesterday's mic comment about … Daniel Franke
- [Ntp] Antw: Follow-up to yesterday's mic comment … Ulrich Windl
- Re: [Ntp] Antw: Follow-up to yesterday's mic comm… Hal Murray
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Antw: Follow-up to yesterday's mic comm… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Daniel Franke
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Watson Ladd
- [Ntp] Antw: Re: Follow-up to yesterday's mic comm… Ulrich Windl
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … Harlan Stenn
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Heiko Gerstung
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … Miroslav Lichvar
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Daniel Franke