Re: [Ntp] Mandatory confidentiality for ntpv5

Hey all,

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

Such a ZCL mode would work by using a message flow a bit like two-step 
from PTP, where the time server/master/source sends two messages to 
compensate for any delays in the first one via contents of the second one.
It can still be done, it just gets more complex with a mandate to "simply 
encrypt everything".

That said, encrypting everything might still be the right call, at least 
it makes for less complex policy decisions, and fits well within IETF 
guidelines.

Best regards,
Kristof

Von:    "Dieter Sibold" <dsibold.ietf@gmail.com>
An:     "Hal Murray" <halmurray+ietf@sonic.net>
Kopie:  "NTP WG" <ntp@ietf.org>
Datum:  20.10.2021 19:17
Betreff:        Re: [Ntp] Mandatory confidentiality for ntpv5
Gesendet von:   "ntp" <ntp-bounces@ietf.org>

On 15 Oct 2021, at 21:41, Hal Murray wrote:

> james.ietf@gmail.com said:
>> Perhaps you can elaborate why you think confidentiality in NTP is a bad
>> idea?
>
> Is it going to do any good?
>
> There is/was a draft on client data minimization.  What is happening 
with that?
>  https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization
>
> After you have minimized things, what is left to hide with encryption?
>
> Maybe we should encrypt everything so that we don't waste time 
discussing
> whether we need to encrypt everything.
>
Maybe this is not a bad idea. NTS already has the capability to encrypt 
content.
> -------
>
> We need something like a version field in order for a server to be able 
to
> support multiple versions on the same port number.  That allows a 
fraction of
> a bit for client tracking, probably closer to a whole bit for early 
adopters
> when the version is changing.
>
> --------
>
> I'm chasing buggy clients that send bursts of requests to pool servers. 
It
> would be convenient to have the name and version of the NTP package that
> generated the packet inside the packet where I can see it.  :)
>
>
> -- 
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp