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