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

[Daniel Franke <[e-mail]>]

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?
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg