Re: [Ntp] Mandatory confidentiality for ntpv
kristof.teichel@ptb.de Thu, 21 October 2021 12:17 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 AA07F3A1110; Thu, 21 Oct 2021 05:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SW5CrvkJpY0U; Thu, 21 Oct 2021 05:17: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 4752C3A10EB; Thu, 21 Oct 2021 05:17: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 19LCHhDk020796-19LCHhDm020796 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Oct 2021 14:17:43 +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 CA757C52BBA; Thu, 21 Oct 2021 14:17:43 +0200 (CEST)
In-Reply-To: <20211021112322.685ED28C0F3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
References: <20211021112322.685ED28C0F3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
To: Hal Murray <halmurray+ietf@sonic.net>
Cc: ntp@ietf.org, ntp <ntp-bounces@ietf.org>
MIME-Version: 1.0
Message-ID: <OF272DA7DC.84A53FFD-ONC1258775.0041F7CE-C1258775.004389E4@ptb.de>
From: kristof.teichel@ptb.de
Date: Thu, 21 Oct 2021 14:17:42 +0200
Content-Type: multipart/alternative; boundary="=_alternative 004389E3C1258775_="
X-FE-Policy-ID: 5:5:5:SYSTEM
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Jp20Tfe6axSNexmmdDWPSAmmscw>
Subject: Re: [Ntp] Mandatory confidentiality for ntpv
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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, 21 Oct 2021 12:17:53 -0000
"ntp" <ntp-bounces@ietf.org> schrieb am 21.10.2021 13:23:22: > > kristof.teichel@ptb.de said: > > for the record, mandating encryption for NTP synchronization > packets has one > > minor disadvantage that I can think of: It makes it more difficult to > > introduce something like a "zero-cryptographic-latency" (let me call that > > ZCL) mode (like ANTP for > > How much of a problem is that? I currently believe it is a minor inconvenience. Mostly, I'm afraid it will increase the complexity threshold for a "high accuracy/high performance" option for NTP just enough so that we as a WG will refuse to engage with it. > Part of the problem exists even without any crypto. You still have to get > through the kernel and hardware before the packet gets to the wire. That is correct. The thing that gets more complicated is to invent a mode that "simply" retains the performance of regular old unsecured NTP in spite of using (something like) NTS. Once you move on to eliminating more/all of the eliminate-able delay (such as kernel timestamping delays) and move closer to what PTP's two-step functionality does, it probably doesn't matter anymore whether you chose to encrypt or not. > How much error does a dumb approach introduce? > How much is left if you measure how long the crypto takes and bump the > time-stamp ahead by that much? We decided against this approach a number of times. One reason being that the error can be however much your predicitve measurement differs from your concrete execution time in a given instance. At least with the way it is now, your error can only happen in one direction, because the order of events is retained (you take your timestamp, then stuff happens, then the message goes to the wire). I'm in favor of keeping it this way; it would have made security/reliability analysis even more of a pain if this hadn't been a given. > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp
- Re: [Ntp] Mandatory confidentiality for ntpv kristof.teichel
- Re: [Ntp] Mandatory confidentiality for ntpv Hal Murray