Subject: Re: [Ntp] Mandatory confidentiality for ntpv

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 04:23:22 -0700

[email-masked] 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?

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.

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?

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Thu, 21 Oct 2021 14:17:42 +0200

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

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

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

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp