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

[Danny Mayer <[e-mail]>]

On 10/15/21 5:27 AM, James wrote:
> 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.
Encryption needs to be off the table. It's not just a bad idea, it 
provides no benefits. Time is not a confidential matter. If you have 
some use cases for encryption, please state them.
>
>> 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.
>
Leap seconds needs work. I have an idea to add a leap second info piece 
to the base packet that will not only tell you if a leap second is in 
progress, but also when the last one occurred and the number of leap 
seconds added since TAI but also if one is coming up when it will occur 
and the new number of leap seconds instead. In addition, if leap 
smearing is in progress then the type of smearing (by ID maintained by 
IANA). This allows a client to filter out leap smearing or type of leap 
smearing it doesn't want.

Danny