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

[James <[e-mail]>]

The problem you’re expressing here does not appear to be at odds with my proposal. All that changes is that instead of the server smearing the time it transmits, the NTP client can optionally smear the clock it is synchronising instead. A server that supports both v4 and v5 must not smear v5 timestamps, but it can smear v4.

The alternative approaches are as I see it:
1. Continue the status quo, where we have no way to signal smearing, no consistent smearing cadence, and clients avoiding mixing smeared/non-smeared servers. Nothing improves.
2. Introduce some means to communicate the existence of smearing, and either standardising the smearing cadence or have some way of signalling it. Clients may be able to mix same-cadence smearing servers but cannot mix between smearing and non-smearing. This only legitimises the status quo bodge and makes it explicit.

The people who are making the call are absolutely welcome to come participate in this discussion and provide further information. It would be great to understand more details about their use cases.

- J

> On 15 Oct 2021, at 17:53, Doug Arnold <[e-mail]> wrote:
> 
> Hello James,
>  
> I agree that leap smearing is a clumsy and dangerous way to avoid the complication of correctly handling leap seconds in distributed database software.  And if it was up to me all IT equipment would use TAI for all timing except what is displayed to humans.  But it is not up to me.  The people who are making the call tell me that they believe that leap seconds is less bad than either moving everything from UTC to TAI, or writing and debugging database software that manages leap seconds properly.
>  
> So given that state of affairs.  What do we do? 
>  
> Doug
>  
> From: James <[e-mail]>
> Date: Friday, October 15, 2021 at 5:27 AM
> To: Doug Arnold <[e-mail]>
> Cc: NTP WG <[e-mail]>
> Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
> 
> Doug,
> Thanks for the feedback, responses inline.
> 
> 
> On 15 Oct 2021, at 00:45, Doug Arnold <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Thanks James,
>  
> I think that this is pretty close to what is needed for ntpv5.  I like the separation of protocol and algorithms, and the use of monotonic timescale for timestamp fields (at least by default), and the insistence on security. 
>  
> I have two comments:
> 1. Why do you think that encryption should be the default mode? People often consider timing information to be critical but not secret.  Also it is likely to affect accuracy in implementations by adding a variable delay to encrypt. 
>  
> We’ve had a few discussions on list on the subject in the past, and the draft says:
>  
> > 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.
>  
> 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.
>  
> - J
>  
> 1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4 <https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4>
> 2: https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/ <https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/>