Subject: [ntpwg] suggestions for draft-ietf-ntp-data-minimization

From: Job Snijders <[email-masked]>
Date: Tue, 18 Jul 2017 16:04:23 +0200

Dear group,

I have two suggestions that can go into draft-ietf-ntp-data-minimization-01,
I unicasted these to the authors but I should've sent them to the
mailing list directly.

The first suggestion comes straight from RFC7942 and serves to promote
creation of running code and provides an overview of known running code.
The second suggestion is to provide historical context and to provide an
indicator that standardisation of (old) good practises is worthwhile.

Kind regards,

Job

---
OLD:
    (none)

NEW:
    6.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION

       This section records the status of known implementations of the
       protocol defined by this specification at the time of posting of
       this Internet-Draft, and is based on a proposal described in
       RFC7942. The description of implementations in this section is
       intended to assist the IETF in its decision processes in
       progressing drafts to RFCs. Please note that the listing of any
       individual implementation here does not imply endorsement by the
       IETF. Furthermore, no effort has been spent to verify the
       information presented here that was supplied by IETF
       contributors. This is not intended as, and must not be construed
       to be, a catalog of available implementations or their features.
       Readers are advised to note that other implementations may exist.

       As of today the following vendors have produced an implementation
       of the NTP Client Data Minimization recommendations described in
       this document.

          OpenNTPD
---

---
OLD:
    Appendix A.  Acknowledgements
       The authors thank Prof. Sharon Goldberg and Miroslav Lichvar for
       calling attention to the issues addressed in this memo.

NEW:
    Appendix A.  Acknowledgements
        The authors would like to gratefully acknowledge Henning Brauer
        for pioneering NTP data minimization techniques as early as
        <eref target="http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/client.c?rev=1.1">
        June 2004</eref> as part of an NTP implementation for the
        OpenBSD Project. 

        The authors would like to thank Prof. Sharon Goldberg and
        Miroslav Lichvar for encouraging standardisation of the approach
        described in this document.
---
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 05:15:19 +0000

I believe the data minimization proposal is about to become an
informational proposal, as everything it wants to do can be done by
using the SNTP client-mode spec described in RFC-5905.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 28 Jul 2017 09:25:59 +0400

> Dear group,

Hello job@ :)

Please see:
http://lists.ntp.org/pipermail/ntpwg/2017-May/003298.html
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Jul 2017 11:06:48 +0200

Dear Harlan,

> using the SNTP client-mode spec described in RFC-5905.

The choice the working group will have to make, is whether the WG merely
wants to document that privacy enhancing tricks exist ("informational")
or whether the data minimization techniques outlined should be mandatory
for each (s)ntp client ("standards track").

Since the current draft updates 5905 (which is a standards track
document) the update itself should probably be of on the standards level
as well. 

I consider it a great feature that on-the-wire the proposed techniques
is backwards compatible with the existing standards, however in my
opinion it doesn't necessarily follow that because of 'backwards
compatibility' the intended needs to be downgraded.

I would appreciate if someone offers insight what the advantages are of
downgrading the intended status, or what the downsides are of keeping
the current intended status.

Kind regards,

Job

ps. There was a 10 days delay for my email to make it to the list :(
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Jul 2017 11:33:24 +0200

Dear Loganaden,

On Fri, Jul 28, 2017 at 09:25:59AM +0400, Loganaden Velvindron wrote:
> Please see: http://lists.ntp.org/pipermail/ntpwg/2017-May/003298.html

I copy+pasted your message below:

On Mon May 29 08:26:35 UTC 2017, Loganaden Velvindron wrote:
> I've looked into openntpd, and transmit timestamp  is already
> randomized using arc4random():
> client.c line 188:
>         p->query->msg.xmttime.int_partl = arc4random();
>         p->query->msg.xmttime.fractionl = arc4random();
> 
> Perhaps a small section could be added for open source implementations
> who have already implemented this ?
> 
> Also, suggest using arc4random() as an example of a randomization
> function might offer guidance to implementors ?

The working group needs to make a conscious choice whether to zero out
those bits or fill those fields with random stuff (with arc4random() for
example).

Whatever the recommendation ends up being, it probably is one that we'd
want as many clients as possible to follow to prevent giving away hints
about the NTP client's operating system/implementation (since such
meta-data can also compromise a degree of privacy).

My personal preference would be to simly zero out the bits and suggest a
patch to the openntpd project. Even the simplest of clients will be able
to produce zeros in a very short timespan, I imagine not all clients
have access to arc4 functions or sufficient entropy.

Look forward to any feedback on this.

Kind regards,

Job

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 02:34:35 -0700

Hi Job,

> document) the update itself should probably be of on the standards level

The current draft *proposes* to update RFC5905.

I was passing along Dave's comments, and my recollection from the WG
meeting was that the authors were ready to make the document
informational.  I had some other comments to the proposal that I
submitted that haven't been published to the mailing list yet.

> the current intended status.

The proposal simply describes one way to implement what is already
present in RFC5905, section 14, the last paragraph, which states:

   An SNTP client implementing the on-wire protocol has a single server
   and no dependent clients.  It can operate with any subset of the NTP
   on-wire protocol, the simplest approach using only the transmit
   timestamp of the server packet and ignoring all other fields.
   However, the additional complexity to implement the full on-wire
   protocol is minimal so that a full implementation is encouraged.

The data minimization proposal (ie, minimal data in an SNTP packet) is
great for client mode.  It is not something that should be used for
other modes.

> ps. There was a 10 days delay for my email to make it to the list :(

Yes, there was a problem with the list and it's only now being fixed.

As Karen said in the meeting, when the mailing list works there's no
rush to move it, and the list has been working fine for a while.  It
broke just before the meeting.  NTF doesn't yet have the support to hire
a sysadmin, and the existing volunteer sysadmins have real jobs and
limited time.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Jul 2017 11:52:28 +0200

Dear all,

On Fri, Jul 28, 2017 at 02:34:35AM -0700, Harlan Stenn wrote:
> > The choice the working group will have to make, is whether the WG
> > merely wants to document that privacy enhancing tricks exist
> > ("informational") or whether the data minimization techniques
> > outlined should be mandatory for each (s)ntp client ("standards
> > track").
> > 
> > document) the update itself should probably be of on the standards
> > level as well.
> 

Yes, I understand drafts are proposals.

> informational.

I've reviewed the video recording from the working group meeting and I
don't believe clear consensus was reached. The authors clearly indicated
a desire to get something published on this topic. My interpretation was
that they are willing to continue dialogue regarding the intended
status.

Since this is a working group document, even if the authors think that
"Informational" is an appropiate status for this document I'd like to
that reflected through discussion on the mailing list. At this moment I
don't see a clear reason to downgrade the intended status, specifically
in context of https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

> I had some other comments to the proposal that I submitted that
> haven't been published to the mailing list yet.
> 
> > I consider it a great feature that on-the-wire the proposed
> > techniques is backwards compatible with the existing standards,
> > however in my opinion it doesn't necessarily follow that because of
> > 'backwards compatibility' the intended needs to be downgraded.
> > 
> > I would appreciate if someone offers insight what the advantages are
> > of downgrading the intended status, or what the downsides are of
> > keeping the current intended status.
> 

The above text paints a broader picture of what is possible, and
subsequently what draft-ietf-ntp-data-minimization can do is narrow down
those possibilities to a specific subset, decorated with normative terms
to encourage implementers to do things a specific way, based on
experience gathered in the years between publication of 5905 and now.

In other words: the fact that draft-ietf-ntp-data-minimization fits
within what is outlined in Section 14 of RFC 5905; by itself is not an
indicator whether the draft's intended status should be Standards or
Informational.

> great for client mode.  It is not something that should be used for

Yes, the draft confines itself to mode 3, the last paragraph of the
Introduction section reads:

    """
    This memo updates RFC 5905 to redact unnecessary data from mode 3
    packets.  This is a fully backwards-compatible proposal.  It calls
    for no changes on the server side, and clients which implement these
    updates will remain fully interoperable with existing servers.
    """

Do you feel additional clarification is needed?

Kind regards,

Job

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 28 Jul 2017 12:35:51 +0200

> have access to arc4 functions or sufficient entropy.

I agree! The current draft proposes to zero out the bits for unused fields
(which excludes the transmit timestamp ofcourse) in the mode 3 client
packet. I don't see any particular advantage in randomizing those bits.
Please bring to my notice if there is any.

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 28 Jul 2017 12:35:34 +0200

> submitted that haven't been published to the mailing list yet.

We never agreed on the status of the document to be "Informational". The
only consensus we reached at the WG meeting was to get the document
published. The intended status of the document has always been "Standards
Track". This document updates RFC5905 by concretely specifying the methods
of data minimization for (S)NTP as opposed to a general statement in the
section 14 of RFC5905. So I would prefer  the document to be "Standards
Track" to encourage as broad as possible deployment by making this behavior
part of the core NTP specification.

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Fri, 28 Jul 2017 12:39:46 +0000

Subject: RE: [ntpwg] suggestions for draft-ietf-ntp-data-minimization
From: "Salz, Rich" <[email-masked]>
To: Job Snijders <[email-masked]>, Harlan Stenn <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 28 Jul 2017 12:39:46 +0000

This should not be informational, it should be standards track.  Data minimization is an important part of IETF goals these days.

The fact that it can be done in a major client without code changes is great.  But should not affect the value of the document.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Karen ODonoghue <[email-masked]>
Date: Fri, 28 Jul 2017 11:02:01 -0400

I agree with Rich. Given the guidance from the IESG, this should be 
standards track.

Karen

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 14:08:53 -0700

> part of the core NTP specification.

Then I completely mis-heard and misunderstood you and Daniel.

I'm fine having this as an OPTION for client queries.

But it's already clearly permitted behavior for an SNTP client, so it's
not adding anything new.

If you want this as REQUIRED behavior for all CLIENT (mode 3), what
you're talking about is no longer NTP, and you should propose an
alternative Standard for your purposes.

If you want this as REQUIRED behavior for more than CLIENT (mode 3)
requests, what you are talking about is no longer NTP, and you should
propose an alternative Standard for your purposes.

There are plenty of use-cases where the existing behavior is useful and
desirable.

It is wrong to prohibit these cases.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 14:11:33 -0700

> The fact that it can be done in a major client without code changes is great.  But should not affect the value of the document.

Then let's clean up RFC5095, section 14, last paragraph.

The data minimization must be OPTIONAL, and it must clearly be limited
to CLIENT (mode 3) packets.

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Jul 2017 21:28:00 +0000

On Fri, 28 Jul 2017 at 23:11, Harlan Stenn <[email-masked]> wrote:

> > This should not be informational, it should be standards track.  Data
> minimization is an important part of IETF goals these days.
> >
> > The fact that it can be done in a major client without code changes is
> great.  But should not affect the value of the document.
>

Why must it be optional? You offer no argument here.

The reverse makes more sense: by default apply minimization, optionally do
something else.

Kind regards,

Job

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 28 Jul 2017 23:47:05 +0200

On Fri, Jul 28, 2017 at 11:08 PM, Harlan Stenn <[email-masked]> wrote:

> merely
> level

>From Section 1 of the proposed draft

"This memo updates RFC 5905 <https://tools.ietf.org/html/rfc5905> to
redact unnecessary data from mode 3
   packets.  This is a fully backwards-compatible proposal.  It calls
   for no changes on the server side, and clients which implement these
   updates will remain fully interoperable with existing servers."

> It is wrong to prohibit these cases.

Well, it makes more sense to have this as REQUIRED behavior for mode 3
clients for NTP's general use-cases and OPTIONAL otherwise (for the edge
use-cases.)

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 15:19:21 -0700

> clients for NTP's general use-cases and OPTIONAL otherwise (for the edge

The OPTIONAL situation you describe is not an edge case.  It would be
the normal LAN case.

It looks like I'll be resending my comments on the proposal, and I may
end up proposing different language for the implementation of this proposal.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 15:25:38 -0700

> Why must it be optional? You offer no argument here.

Why must it be REQUIRED?  No engineering evaluation of the costs or
tradeoffs if data minimization is used has been offered.

> The reverse makes more sense: by default apply minimization, optionally do

What is your use-case where you believe your statement is true?

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Fri, 28 Jul 2017 22:29:01 +0000

Subject: RE: [ntpwg] suggestions for draft-ietf-ntp-data-minimization
From: "Salz, Rich" <[email-masked]>
To: Harlan Stenn <[email-masked]>, Job Snijders <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 28 Jul 2017 22:29:01 +0000

> The data minimization must be OPTIONAL, and it must clearly be limited to
> CLIENT (mode 3) packets.

Can you explain your reasoning?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Aanchal Malhotra <[email-masked]>
Date: Sat, 29 Jul 2017 00:32:04 +0200

> The OPTIONAL situation you describe is not an edge case.  It would be

It will be useful here to describe how these normal LAN case use the
otherwise unused fields in the mode 3 client packet and how the methods in
the proposed document for data minimization are disruptive to these cases.
Also, is this the most general use-case of NTP?

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 15:38:54 -0700

> Can you explain your reasoning?

I could, and I could spend a lot of time researching the basis for that
position.  But I don't plan to do that now.

>From what we've seen, the problem is the people who are pushing this
agenda are more concerned about apparently small incremental security
benefits, and have shown little awareness about the needs of improving
the quality of network timekeeping, or how this proposal will negatively
affect timekeeping quality.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 15:45:26 -0700

Here's what I wrote on the 17th:

1.  First octet: 0x23  or 0xd3, or explicit language about LI=0 even if
the local clock is unsynchronized.

The Poll field SHOULD be set to either the actual polling interval as
specified by RFC5095, or zero.

4.1: destination timestamp?  Don't think so - that's only for peer
associations, where the information is needed.

This document seems to be an partially-correct re-implementation of SNTP.

==

The poll interval SHOULD be the correct poll interval.  This will make a
big difference for clients that may not handle a leap second properly.

H
--

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Fri, 28 Jul 2017 23:06:27 +0000

Date: Fri, 28 Jul 2017 23:06:27 +0000

> tradeoffs if data minimization is used has been offered.

The IETF is increasingly concerned about anything that can be used to identify, and track, users.  I assume there is no disagreement here.

The type of minimization proposed should be close to zero-cost.

So, minimize unless there's a compelling reason not to.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 16:07:45 -0700

> So, minimize unless there's a compelling reason not to.

Agreed.  Great.  Do your homework.

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Fri, 28 Jul 2017 23:22:27 +0000

Date: Fri, 28 Jul 2017 23:22:27 +0000

> I could, and I could spend a lot of time researching the basis for that position.
> But I don't plan to do that now.

That's unfortunate; do you have previous writings you can point me to?  Or search for on the mailing list archives? Without that, it seems you're asking us to take your assertion as-is.  Am I missing something?
 
> benefits

The opion of various security folks is that minimization is not a small incremental thing.  Preventing end-users from being tracked, on the other hand, *is* important.

> and have shown little awareness about the needs of improving the
> quality of network timekeeping, or how this proposal will negatively affect
> timekeeping quality.

The authors are very familiar with both NTP implementation and security concerns; and, of course, they don't need me to defend them.

How will this proposal negatively affect timekeeping quality?

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 17:31:38 -0700

Rich,

You and I live in different worlds.

H

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Jul 2017 19:15:22 -0700

> Do you feel additional clarification is needed?

Draft 1 cleaned up a lot of the problems.

Since little is written about section 3 and the Poll field, I'd want to
think about that a bit more.  In particular, we should say something
about the client needing to pay attention to the poll value returned by
the server.  There may be implications here about the Precision field.

How about describing the reasoning behind:

   While populating any of these fields with authentic data reveals at
   least some identifying information about the client, the Origin
   Timestamp and Receive Timestamp fields constitute a particularly
   severe information leak.

Exactly *how* is the origin timestamp a *severe* information leak?

Exactly when is the Receive timestamp nonzero in a client mode packet?

---

From: Paul Gear <[email-masked]>
Date: Sat, 29 Jul 2017 13:16:52 +1000

On 29/07/17 07:28, Job Snijders wrote:
>
> On Fri, 28 Jul 2017 at 23:11, Harlan Stenn <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > This should not be informational, it should be standards track. 
>     Data minimization is an important part of IETF goals these days.
>     >
>     > The fact that it can be done in a major client without code
>     changes is great.  But should not affect the value of the document.
>
> The reverse makes more sense: by default apply minimization,
> optionally do something else.

Hi everyone,

I'd like to offer a small data point from a non-expert.  (Apologies for
the length; I've got the flu at the moment - I hope the logic is clear
even if my head is not.)

At the risk of repeating myself [1], during the NTP pool Snapchat
traffic surge last December (2016) [2], the time to discovery of the
issue was increased due to the fact that the pool server operator
community had no way of identifying the traffic's source.  It was over 4
days days between my initial report of the traffic surge on the pool
list [3] and the eventual discovery of a Snapchat update as the culprit
after some collaboration on the NANOG list [4].

One could argue that because this event spanned the US weekend, it would
have been resolved far more quickly had it occurred during the normal
work week, but had Snapchat (or the NTP library it uses) [5] had some
method of communicating something equivalent to a user agent string, we
would have stumbled on the cause within minutes.  (Of course, if they'd
used a vendor pool, Ask Bjørn Hansen and the pool infrastructure
operators would have been able detect it on the NTP pool DNS servers.)

The way this issue was discovered was via sniffing the wire and
correlating NTP & DNS from an individual client IP address.  Any
nation-state attacker or other MitM would have the ability to infer the
source of the traffic regardless of the data in the NTP packet, whereas
the pool operator community was blind to it.  So in this particular
case, I believe data minimisation would offer no practical privacy
benefit (contra Daniel's reply [6]), whilst adding considerable cost in
troubleshooting & remediation time to the pool operator community. 
(Some servers dropped out due to their bandwidth being overwhelmed.)

I still think this debate would be benefited by Harlan further engaging
and expressing other positive points against minimisation (although I'm
guessing it would just be a recapitulation of [7] - that NTP has very
little value for fingerprinting purposes), but I would prefer to see
clients given the option of including something akin to a user agent
field by default.

If I'm not mistaken, the most reliable method of preventing client
fingerprinting via NTP would be to use IPv6 SLAAC privacy extensions (as
far as I'm aware, there's no way to encrypt IPv4 DHCP traffic),
encrypted DNS, and NTS (although MitMs could still sniff actual poll
intervals).  Can any experts confirm, deny, or nuance for me?

Regards,
Paul

 1. http://lists.ntp.org/pipermail/ntpwg/2017-March/003179.html
 2. https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18/10
 3. http://lists.ntp.org/pipermail/pool/2016-December/007996.html -
    2016-12-15 00:04:47 UTC; as far as I can tell, this was the earliest
    English language reference to the issue.
 4. https://mailman.nanog.org/pipermail/nanog/2016-December/089588.html
    - 2016-12-19 21:13:09 UTC.
 5. https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122

    https://twitter.com/paulgear1/status/810967841226657792 
 6. http://lists.ntp.org/pipermail/ntpwg/2017-March/003188.html
 7. http://lists.ntp.org/pipermail/ntpwg/2017-March/003202.html

---

From: "Salz, Rich via ntpwg" <[email-masked]>
Date: Mon, 31 Jul 2017 12:54:43 +0000

Subject: RE: [ntpwg] suggestions for draft-ietf-ntp-data-minimization
From: "Salz, Rich" <[email-masked]>
To: Paul Gear <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 31 Jul 2017 12:54:43 +0000

Paul,

Thanks for your detailed note. The anecdote makes clear that end-user privacy and the ability to debug and sometimes protect our infrastructure, are at times in conflict.

Recall that a major concern of the minimization work is not for a single client/server interaction, but rather being able to track clients as they move around and talk to multiple servers.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg