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

From: Karen O'Donoghue <[email-masked]>
Date: Sun, 26 Mar 2017 21:52:11 +0000

Folks,

We agreed to adopt this at the last IETF meeting, but we didn’t actually issue a call for adoption.

https://datatracker.ietf.org/doc/html/draft-dfranke-ntp-data-minimization

If you are in any way opposed to the adoption of this draft as a working group document, please reply to the mailing list. We will be taking silence as consent because we did discuss this in Seoul.

Regards,
Karen and Dieter

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 26 Mar 2017 18:08:56 -0700

> If you are in any way opposed to the adoption of this draft as a working group document, please reply to the mailing list. We will be taking silence as consent because we did discuss this in Seoul.

Section 3:

- Change the recommendation for the LI, version number and mode fields
from SHALL to MAY.

- Change the recommendation for the Transmit Timestamp from SHALL to MAY.

- Change the recommendation for  "All the other header fields ..." from
SHALL to MAY.

These changes have benefit for protecting packets sent over the Big Bad
Internet in cases where traffic can be watched,  but *requiring* this
change in more trusted environments is of questionable and/or minimal
security benefit, and it does make debugging and some monitoring on the
LAN more difficult.

Section 4.2:

Delete the last paragraph:

   The traditional behavior of the NTP reference implementation is to
   randomize only a few (typically 10-15 depending on the precision of
   the system clock) low-order bits of transmit timestamp, with all
   higher bits representing the system time, as measured just before the
   packet was sent.  This is suboptimal, because with so few random
   bits, an adversary sending spoofed packets at high volume will have a
   good chance of correctly guessing a valid origin timestamp.

It is incomplete and contains inaccuracies, aside from its inflammatory
characteristics.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Paul Gear <[email-masked]>
Date: Mon, 27 Mar 2017 09:17:12 +1000

On 27/03/17 07:52, Karen O'Donoghue wrote:
> If you are in any way opposed to the adoption of this draft as a
> working group document, please reply to the mailing list. We will be
> taking silence as consent because we did discuss this in Seoul. 
>
> Regards,
> Karen and Dieter

Just a quick question: Were costs/downsides of data minimization
discussed at the meeting?  In the light of the Snapchat NTP surge last
December, there is an argument to be made that identifying and tracking
classes of clients (in this case, users of a badly-behaved NTP client
library) is necessary to ensure ongoing reliability of public NTP service.

Thanks in advance,
Paul

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 26 Mar 2017 18:21:13 -0700

Paul illuminated a case I had forgotten.  +1.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 27 Mar 2017 15:22:30 +0200

> library) is necessary to ensure ongoing reliability of public NTP service.

Maybe the reference ID and/or reference timestamp in client mode
packets could be used as a User-Agent field?

Some NTP implementations can be identified quite reliably by looking
at the distribution of their polling interval and setting all fields
to zero would not prevent that, but with these libraries and
applications where NTP requests are triggered randomly by some user
action, a User-Agent string would help a lot.

The question is they would actually set that field.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 27 Mar 2017 15:38:42 +0200

> https://datatracker.ietf.org/doc/html/draft-dfranke-ntp-data-minimization

Just a minor issue, but I'd like to ask the group to consider setting
the precision field to 32 instead of 0 to make it clear that the
timestamps are completely random in the original sense that only bits
below precision can be random. This might be useful in debugging and
traffic analysis.

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Mon, 27 Mar 2017 14:13:48 +0000 (UTC)

Subject: RE: [ntpwg] call for adoption (draft-dfranke-ntp-data-minimization)
From: "Salz, Rich" <[email-masked]>
To: Miroslav Lichvar <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 27 Mar 2017 14:13:31 +0000

> Just a minor issue, but I'd like to ask the group to consider ...

Just as a point of clarification, adoption means the WG wants to take the document and start making changes.  Not that it's good and ready to go as-is.

---

From: Sharon Goldberg <[email-masked]>
Date: Mon, 27 Mar 2017 10:13:34 -0400

Miroslav, can you clarify? What section of the draft are you talking about?

Sharon

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Mar 2017 11:31:59 -0400

> - Change the recommendation for  "All the other header fields ..." from

I think there's a reasonable case to made that all the MUSTs for the
client should change to SHOULD, since the behavior doesn't impact
interoperability and is only for the client's own benefit. But I think
MAY is clearly inappropriate and defeats the purpose of the document.

The language specifying that servers MUST accept packets that conform
to these recommendations *does* impact interoperability and has to
stay. (This requirement is the only reason that this document is
intended for standards track status; otherwise it cold be
informational).

> It is incomplete and contains inaccuracies, aside from its inflammatory

What would you add to correct the incompleteness? What are the
inaccuracies? What statements do you regard as inflammatory and how
would you temper them?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 27 Mar 2017 17:35:35 +0200

> Miroslav, can you clarify? What section of the draft are you talking about?

In section 3 there is:

  All other header fields, specifically the Stratum, Precision, Root
  Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin
  Timestamp, and Receive Timestamp, SHALL be set to zero.

My suggestion is to remove Precision from that list and add before
that paragraph: Precision SHALL (or SHOULD?) be set to 32.

Anyway, do the all other fields need to be zero? As long as they are
constant and not unique to the individual clients, as in most SNTP
implementations they currently are, it wouldn't be a problem, right?

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 27 Mar 2017 11:48:58 -0400

> implementations they currently are, it wouldn't be a problem, right?

Setting these fields to zero or any other constant value is fine. But it
should be the same for ALL clients and for EACH request. Or alternatively,
each client could randomize these fields for every request.
Is there any operational issues with zeroing out these fields anyway?

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Mar 2017 12:02:17 -0400

> The question is they would actually set that field.

I think the answer to that question is almost always going to be "no",
or at least often enough that there is no benefit to implementing
this. It's also harmful to privacy since the user agent is information
that could be used for fingerprinting. And in any case, anyone who
chooses to implement something like this should put it in an extension
rather than changing the semantics of an existing field.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 27 Mar 2017 18:05:09 +0200

> each client could randomize these fields for every request.

Could this be included in the draft?

> Is there any operational issues with zeroing out these fields anyway?

Maybe with the exception of more difficult identification of broken
implementation, I guess not.

I was mostly interested in minimizing the changes that will be needed
in existing (S)NTP implementations.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Mar 2017 12:08:35 -0400

> Is there any operational issues with zeroing out these fields anyway?

I picked 0 rather than 32 because that's what OpenNTPD uses (and
always has) and, to prevent fingerprinting, I want consistency across
implementations. Otherwise I'd have no objection to changing it. Also,
I marginally prefer fixed values over random ones. Randomizing these
fields is pointless extra computation and could exacerbate CSPRNG
flaws (c.f. the controversy a couple years ago about
tls-extended-random).
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 13:30:59 -0700

Daniel,

> flaws (c.f. the controversy a couple years ago about

It would help if you properly quoted your context.

I don't see a '32' anywhere in what Aanchal said, above.

Assuming this is about the poll interval, I have 2 comments:

- Bluntly, OpenNTPD would not be my first choice for a source for NTP
protocol experience or knowledge.

- There is likely benefit to knowing the client's poll interval in
certain situations so the server can recommend changes to the poll
interval.  This becomes more difficult if the server doesn't know what
the client's poll interval is.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 13:44:20 -0700

> rather than changing the semantics of an existing field.

I still have difficulty believing that NTP is a useful fingerprinting
avenue, and I still think this is pretty much a "tempest in a teapot".

Does anybody have an evidence that a real problem is being solved here?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 13:46:14 -0700

Ah, precision.

Where's the problem in having the precision value be accurate?

H
--

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Mar 2017 16:50:42 -0400

> I don't see a '32' anywhere in what Aanchal said, above.

The context I should have included was from Miroslav upthread:

> protocol experience or knowledge.

Regardless of your opinion of OpenNTPD design choices, the facts
remain that it's in wide deployment and sets the precision field to
zero.  Those facts alone make it a good choice for standardization
since:

1. Matching an existing implementation leads to one less opportunity
for fingerprinting.
2. Existing widespread use of this value means we can be confident it
won't break anything.

> the client's poll interval is.

You were confused here about which field we were discussing. Zeroing
the poll interval is already a MAY in the current draft, partly
because we want to allow for exactly this sort of thing.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Mar 2017 16:53:51 -0400

> Where's the problem in having the precision value be accurate?

Same problem as every other field: it's data that can be used for
fingerprinting. In this particular case, it's a problem even if the
client never moves between networks, since the precision value carries
information that can help an eavesdropper guess the client's hardware
and OS.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 13:58:13 -0700

> information that can help an eavesdropper guess the client's hardware

OK, and we're back to my wondering how much of this is "conspiracy theory".

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 14:01:13 -0700

> 2. Existing widespread use of this value means we can be confident it

If they made a suboptimal choice we should take this opportunity to make
a better choice.

My previous discussions on the usefulness of this sort of fingerprinting
are still unanswered.

There is no reason to believe that one arbitrary value for this is
somehow "magical" and a different arbitrary value would be dangerous.

> because we want to allow for exactly this sort of thing.

OK.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 14:06:32 -0700

If we're saying "our values have poor precision" there's a better
argument to be made for using a positive number that is less than 128.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 19:06:53 -0700

My bad - I was thinking about error bounds, not precision.

I'm with Miroslav on 32 being the right value in this case.

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 28 Mar 2017 08:05:22 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 27.03.2017 um 15:38 in
Nachricht <20170327133842.GK8192@localhost>:
>> We agreed to adopt this at the last IETF meeting, but we didn’t actually

> issue a call for adoption.
>> 

What's the problem with 0?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 27 Mar 2017 23:07:19 -0700

> What's the problem with 0?

It means "our clock/timestamps are accurate to 1 second" and for the
data in the timestamp, that's not true.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 28 Mar 2017 08:23:45 +0200

>>> Daniel Franke <[email-masked]> schrieb am 27.03.2017 um 22:50 in
Nachricht
> remain that it's in wide deployment and sets the precision field to

Do you have numbers for "wide deployment"? I guess Microsoft's implementation of NTP has widest deployment, I I wouldn't take it as a reference ;-)

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 28 Mar 2017 08:35:53 +0200

>>> Daniel Franke <[email-masked]> schrieb am 27.03.2017 um 22:53 in
Nachricht
> fingerprinting. In this particular case, it's a problem even if the

I just did a little test among eight different servers:
precision=-22,
precision=-22,
precision=-22,
precision=-23,
precision=-20,
precision=-22,
precision=-22,
precision=-21,

The hardware (and OS) of the first seven is identical; the last one has a different hardware (but same OS).

Do you really thing you can fingerprint the server from precision?

For challenge, I've included three more different hardwares:
precision=-22,
precision=-22,
precision=-22,
precision=-23,
precision=-20,
precision=-22,
precision=-22,
precision=-21,
precision=-21,
precision=-18,
precision=-21,

Regards,
Ulrich

---

From: Hal Murray <[email-masked]>
Date: Tue, 28 Mar 2017 00:17:22 -0700

> Do you really thing you can fingerprint the server from precision?

It's another fraction of a bit.  Collect enough of them and you can identify 
a system and/or user.

-- 
These are my opinions.  I hate spam.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 28 Mar 2017 09:23:47 +0200

> https://datatracker.ietf.org/doc/html/draft-dfranke-ntp-data-minimization 

 I'd suggest to move the explanation for transmit time randomization from "security considerations" to the actual proposal. Also with 11 to 14 bits of randomness for todays clients I wonder whether sending a bunch of 2000 to 16000 bad response packets will remain undetected by the client (in case of an attack).
IMHO it would be consistent to set precision to 3 (the lowest possible precision (0.125s) where NTP will start to work) and use 29 bits of randomness then. Still a half billion attack packets might transit without being detected, but I doubt that.

Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 Mar 2017 00:38:04 -0700

On 3/28/17 12:23 AM, Ulrich Windl wrote:
> I'd suggest to move the explanation for transmit time randomization
> from "security considerations" to the actual proposal. Also with 11
> to 14 bits of randomness for todays clients I wonder whether sending
> a bunch of 2000 to 16000 bad response packets will remain undetected
> by the client (in case of an attack). IMHO it would be consistent to
> set precision to 3 (the lowest possible precision (0.125s) where NTP
> will start to work) and use 29 bits of randomness then. Still a half
> billion attack packets might transit without being detected, but I
> doubt that.

The NTP Project's software will alert whenever an unexpected origin
timestamp arrives.  So if you start seeing thousands of these arrive you
have knowledge that a bad guy is spoofing you to your server.

Also, for client responses, the "gate" for using this is pretty short -
it's the window between sending the initial request to the server, and
the time the response comes back.

I'm back to wondering how this is not a "tempest in a teapot".

---

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Mar 2017 10:08:16 -0400

On 3/28/17, Ulrich Windl <[email-masked]> wrote:
> IMHO it would be consistent to set precision to 3 (the lowest possible
> precision (0.125s) where NTP will start to work) and use 29 bits of
> randomness then. Still a half billion attack packets might transit without
> being detected, but I doubt that.

2**29 packets is about 541 gigabits including ethernet headers, so on
a 1Gbps link is about a 0.18% chance of attacker success during the 1s
MAXDIST window. On a 10Gbps link this becomes 1.8%. That's a big
improvement over the status quo but still a non-negligible weakness.

What's the benefit of randomizing anything less than the full 64 bits?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Mar 2017 10:20:05 -0400

> have knowledge that a bad guy is spoofing you to your server.

By "alert" you mean "increment a counter whose value can be queried
using ntpq". Few users know this counter exists and almost none
outside this very small community check it routinely. It's absurd to
demand of users that they be keeping constant vigil over the state of
their ntp daemon, and any security model which assumes that they will
do so is useless.

Even if you *do* immediately notice the attack, what are you expected
to do about it? You can either do nothing and let your clock get
manipulated, or disassociate with the peer being spoofed, and if
they're all being spoofed then you're left with letting your clock
free-run. But with proper origin timestamp randomization, you can just
ignore the attack because it will have a negligible chance of success.

> the time the response comes back.

That assumes the legitimate server is alive. The correct "gate" on
which to base success-probability calculations is the MAXDIST
parameter.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 28 Mar 2017 16:26:27 +0200

>>> Daniel Franke <[email-masked]> schrieb am 28.03.2017 um 16:08 in
Nachricht
> What's the benefit of randomizing anything less than the full 64 bits?

IMHO, its just because ist named "transmit timestamp" and not NOUNCE.
(Be are talking about a SHOULD anyway, don't we? So anyone who feel insecure may fill pure random data)

Personally I'd be interested in a real system where NTP contributes most to make a system trackable.

Regards,
Ulrich

---

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Mar 2017 12:08:34 -0400

> Personally I'd be interested in a real system where NTP contributes most to

Who cares whether it's the *biggest* contributor? Identifying
information is cumulative. If NTP is providing any information at all
which isn't perfectly redundant with other sources, then it's
contributing to the problem even if other services are contributing
more.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Tue, 28 Mar 2017 16:13:16 +0000 (UTC)

Subject: RE: [ntpwg] Antw: Re: Antw: Re: call for adoption (draft-dfranke-ntp-data-minimization)
From: "Salz, Rich" <[email-masked]>
To: Daniel Franke <[email-masked]>, Ulrich Windl <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 28 Mar 2017 16:13:00 +0000

To emphasize Daniel's point.

It's not that we care that someone is using "the same" server.  We care that someone can correlate that knowledge with other things, such as their browsing activity at home compared to their browsing history at work.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 Mar 2017 16:23:06 -0700

>> being detected, but I doubt that.

Ulrich, a precision of 3 is 8 seconds.

> improvement over the status quo but still a non-negligible weakness.

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.

- 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.

This has all been said before, several times, and you continue to ignore
these points.

Please take a breath of fresh air.

> What's the benefit of randomizing anything less than the full 64 bits?

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.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Mar 2017 19:40:47 -0400

> implementation from NTF/ntp.org reports these on both the client and the

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.

> timestamp is zeroed in the client so no more responses from the server

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.

> I would generally not choose information hiding or extra randomizing on

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
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 Mar 2017 08:26:52 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.03.2017 um 01:23 in Nachricht

> Ulrich, a precision of 3 is 8 seconds.

Harlan,

you are right, I missed the fact that a signed 24-bit number is used. I forgot about the fact that any real life clock using NTP could have a precision > 0. Of course I meant -3.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 Mar 2017 08:28:21 +0200

>>> Ulrich Windl schrieb am 29.03.2017 um 08:26 in Nachricht <58DB53AC.69E : 161 :
60728>:
> you are right, I missed the fact that a signed 24-bit number is used. I 
> forgot about the fact that any real life clock using NTP could have a 
> precision > 0. Of course I meant -3.

Oops: (Still suffering from DST switch): 8 bit, not 24, of course.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 Mar 2017 11:41:15 +0200

> 1. Matching an existing implementation leads to one less opportunity

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.

> 2. Existing widespread use of this value means we can be confident it

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.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 29 Mar 2017 09:25:43 -0400

> 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.

> 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
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Greg Dowd <[email-masked]>
Date: Wed, 29 Mar 2017 15:37:18 +0000

IIRC, there is a randomizer of a second or two attached to the calculation of the next poll in ntpd?

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Miroslav Lichvar
Sent: Wednesday, March 29, 2017 2:41 AM
To: Daniel Franke <[email-masked]>
Cc: [email-masked]
Subject: Re: [ntpwg] call for adoption (draft-dfranke-ntp-data-minimization)

EXTERNAL EMAIL

> 1. Matching an existing implementation leads to one less opportunity 

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.

> 2. Existing widespread use of this value means we can be confident it 

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.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 29 Mar 2017 11:47:58 -0400

> of the next poll in ntpd?

IIRC you're correct, but the randomization is some number of whole
seconds. The fractional part of the second is determined by whenever
the SIGALRM happens to come in, which is not random. Anyhow, I think
this is clearly out-of-scope for the IETF and should be taken to NTP
implementations' respective development lists.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: [email-masked]
Date: Wed, 29 Mar 2017 20:50:20 +0200

-----"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> wrote: -----

>To: Miroslav Lichvar <[email-masked]>
>From: Daniel Franke 
>Sent by: "ntpwg" 
>Date: 03/29/2017 15:26
>Cc: [email-masked]

I support to use 32.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 30 Mar 2017 08:02:40 +0200

>>> Greg Dowd <[email-masked]> schrieb am 29.03.2017 um 17:37 in Nachricht
> IIRC, there is a randomizer of a second or two attached to the calculation of 

Actually I think this isn't needed considering the fact that today's timers all have sub-second resolution. So it would be enough to distribute the polls within aone second.

Regards,
Ulrich

> 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.
> 
> 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.
> 
> --
> Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 30 Mar 2017 08:06:31 +0200

>>> Daniel Franke <[email-masked]> schrieb am 29.03.2017 um 17:47 in
Nachricht
> the SIGALRM happens to come in, which is not random. Anyhow, I think

Actually I think that part is (depending on the number of fractional digits you look at) actually more random than the rest. With today's CPUs it almost unpredictable to estimate the atual number of cycles a sequence of instructions takes. Do you have real-life statistics material to proove your claims?

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 30 Mar 2017 09:25:48 +0200

> Actually I think that part is (depending on the number of fractional digits you look at) actually more random than the rest. With today's CPUs it almost unpredictable to estimate the atual number o…

I think the stability of the scheduling will depend on the HW, OS, and
how busy is the system. In most cases it will probably be better than
a typical network jitter on the Internet (few milliseconds). You can
check it with tcpdump:

# tcpdump -v -l -n port 123 and host $clientip and 'udp[8] & 15 = 3' | \
  grep '  Transmit'
          Transmit Timestamp:   3699846941.374009549 (2017/03/30 09:15:41)
          Transmit Timestamp:   3699846949.374010294 (2017/03/30 09:15:49)
          Transmit Timestamp:   3699846957.374027043 (2017/03/30 09:15:57)
          Transmit Timestamp:   3699846965.374011576 (2017/03/30 09:16:05)
          Transmit Timestamp:   3699846973.374011486 (2017/03/30 09:16:13)
          Transmit Timestamp:   3699846981.374003976 (2017/03/30 09:16:21)
          Transmit Timestamp:   3699846989.374010205 (2017/03/30 09:16:29)
          Transmit Timestamp:   3699846997.374008774 (2017/03/30 09:16:37)
          Transmit Timestamp:   3699847005.374012529 (2017/03/30 09:16:45)

In this case the ntpd client has scheduling stable to few tens of
microseconds, i.e. the transmit timestamp has about 15 constant bits.