Re: [ntpwg] call for adoption (draft-dfranke-ntp-data-minimization)

[[e-mail]]

-----"ntpwg" <ntpwg-bounces+dieter.sibold=[e-mail]> wrote: -----

>To: Miroslav Lichvar <[e-mail]>
>From: Daniel Franke 
>Sent by: "ntpwg" 
>Date: 03/29/2017 15:26
>Cc: [e-mail]
>Subject: Re: [ntpwg] call for adoption
>(draft-dfranke-ntp-data-minimization)
>
>On 3/29/17, Miroslav Lichvar <[e-mail]> wrote:
>> I'm not sure how much that really helps. Even if other
>implementations
>> sent packets looking exactly like those from openntpd, the timing
>of
>> the packets would still be different. An observer can easily tell
>if
>> it's openntpd, busybox (which is based on openntpd), ntpd, chrony,
>or
>> something else, without actually looking at the values in the
>packets.
>>
>> The fixed one-second timer in ntpd not only helps with
>fingerprinting
>> the implementation, it can be also very useful for fingerprinting
>> individual ntpd instances as they send requests at the same
>sub-second
>> fraction.
>>
>> A specification on how exactly should the timing for a given poll
>> interval look like (e.g. its distribution and granularity) might
>help.
>> However, adjustments of the polling interval that clients normally
>do
>> to adapt to the stability of the clock and network could still be
>> useful for fingerprinting. Suggesting a constant polling interval
>for
>> all NTP clients on the Internet would probably not be a good idea.
>
>So, you've raised two separate issues here.
>
>1. Fingerprinting of individual clients based on the second-fraction
>they choose on startup.
>2. Fingerprinting of implementations based on their scheduling
>algorithm.
>
>The first one is a serious but easy problem (just randomize the
>second-fraction each time). The second is minor but very difficult,
>because it's open-ended and any trivial change to implementation
>might
>lead to some tiny change in timing which could leak something.
>
>I think both of these issues should be out of scope for this
>document.
>This document is addressing interoperability issues by saying that
>certain field values in client packets which are contrary to what's
>specified by RFC 5905 are okay. But RFC 5905 is silent on
>nitty-gritty
>details of packet scheduling; there's nothing there to update.
>
>Is it worth it at all for the IETF to specify NTP packet scheduling?
>I'm inclined toward "no", but if somebody wants to change my mind on
>that then please start a new thread for it so that we don't derail
>this one any further.
>
>Anyway, you've at least convinced me that matching OpenNTPD isn't
>much
>of a reason to choose 0, since it's pretty unlikely that everybody
>else is also going to adopt currently whatever OpenNTPD uses for its
>scheduling algorithm. If there's some future cooperation to make
>scheduling algorithms match, then at that time the OpenNTPD guys can
>just switch their precision field to whatever we decide on.
>
>>> 2. Existing widespread use of this value means we can be confident
>it
>>> won't break anything.
>>
>> 32 is not as common as 0, but it is used too. Another large
>precision
>> that I often see is 118. I've no idea where that comes from.
>
>Okay, if 32 is already in the wild then I guess I really don't care
>either way. So at last count we had two people -- Harlan and Miroslav
>-- who want 32. Does anybody still have an opinion in favor of 0, or
>can we switch to 32 and move on?

I support to use 32.

>_______________________________________________
>ntpwg mailing list
>[e-mail]
>http://lists.ntp.org/listinfo/ntpwg
>

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg