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

[Daniel Franke <[e-mail]>]

On 3/28/17, Harlan Stenn <[e-mail]> wrote:
> Daniel, you're continuing to focus on and assume that:
>
> - nobody will notice or care about these spoofs.  The reference
> implementation from NTF/ntp.org reports these on both the client and the
> server side.

I've already addressed this upthread. Approximately zero percent of
users pay attention to these reports or even know they exist or how to
interpret them, and it is unreasonable to expect them to.

> - Once the client receives the response from the server, the origin
> timestamp is zeroed in the client so no more responses from the server
> will be accepted.

Again, I've addressed this upthread. If you insist on assuming a live
server, then plug in something like a typical ping time and multiply
the success probabilities in my calculation above by that time and
divide by 1 second. I don't think this has any qualitative impact on
the conclusion.

> For extranet communications, I'd likely choose 64 bits.  But I'd also
> consider this to be *my* policy choice.  If somebody has good reason to
> pick a different number, they should be able to.
>
> I would generally not choose information hiding or extra randomizing on
> internal NTP traffic.

Then nobody is trying to restrain you from adding a configuration
option to ntpd which allows the user to adjust this. But since the
vast majority of NTP traffic does go over the internet, I'm going to
continue to maintain that these timestamps SHOULD be fully randomized
and recommend that you make this the default configuration.
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg