Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[Miroslav Lichvar <[e-mail]>]

On Fri, Oct 15, 2021 at 11:27:20AM +0200, James wrote:
> > On 15 Oct 2021, at 00:45, Doug Arnold <[e-mail]> wrote:
> > Encryption and authentication MUST be provided by the protocol specification as a default and MUST be resistant to downgrade attacks...
> 
> To put this another way, I think the specification must provide confidentiality as well as authentication, and that if either is applied they cannot be removed from a connection (aka a security downgrade) which makes authentication the minimum and doesn’t necessarily mandate confidentiality.

I still don't understand this part. What do "as a default" and
"authentication the minimum" exactly mean? What information needs to
be encrypted? Everything? The first octet cannot be encrypted to allow
detection of NTPv5 packets on the port 123.

For NTPv5 to be successful in replacing NTPv4, I think it needs to
support no authentication, symmetric keys and NTS.

> This section in particular could probably use some editing and clarification to better explain this [1] as we’ll likely need consensus calls made.
> 
> > 2. I think that it is better to allow leap smearing and make it a visible part of the protocol than to pretend it is not going to happen.  On this topic I think that Miroslav’s proposal was more realistic.  Data center network architects tell me they definitely plan to continue to do leap smearing.
> 
> In other use cases such as publicly accessible NTP, leap smearing has effectively fragmented the pools of services a given host can use as mixing smeared and non-smeared services is not a good idea, in addition to the start/end and cadence of smearing being inconsistent between providers [2]. I think that having a “linear, monotonic timescale” and leap smearing together are contradictory and so having smearing in the wire format would requiring changing that. My proposal doesn’t prevent smearing of a clock being synchronised, it’s about removing the smear from the wire.

They can be supported both as different timescales, server responding
in the one that the client has requested.

If you don't allow leap smearing in NTPv5 at all, I suspect people
will either stick to NTPv4, missing the important improvements in
NTPv5, or ignore the specification and use a leap-smeared version of
NTPv5 anyway.

Same for UTC vs TAI.

It seems we need to agree on some very high level goals for NTPv5. Is
it supposed to replace most NTPv4 use cases? Is it supposed to be
implementable on current operating systems?

-- 
Miroslav Lichvar