Subject: Re: [Ntp] WGLC: draft-ietf-ntp-data-minimization

From: Samuel Weiler <[email-masked]>
Date: Mon, 5 Nov 2018 14:34:39 -0500 (EST)

I'm delighted to see the WG progressing this doc - data minimization 
is important.  I have some small comments on -03:

Section 3, re: Transmit Timestamp field:

"uniformly at random" is a phrase that doesn't quite make sense to me. 
Could the doc clatify what is meant by "uniformly" in this case?  Or 
maybe remove that word?

Section 4.2, last paragraph:

I'm not used to seeing specific implementations called out in an RFC. 
Perhaps remove this paragraph?  If it must stay in, anonymize it with 
"Some implementations have..."

Poll field:

Like Marcus Dansarie, I noticed the mismatch in language (if not 
intent) between section 3:

    "The Poll field SHOULD be set to either the actual polling
    interval ... or zero."

And section 4:

    "Zeroing the poll field is made optional (MAY rather than
    SHOULD)..."

I would like to see a clear and consistent recommendation.  After 
talking with Harlan, I suggest "SHOULD be set to the actual value ... 
and MAY be set to zero."  I'll leave it to him to explain that choice.

Generally:

Marcus Dansarie's 3 September comments appear to not have been 
addressed.

-- Sam

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 19 Nov 2018 16:14:55 -0500

Hi Samuel,

Thank you for your comments. Response inline.

> Could the doc clatify what is meant by "uniformly" in this case?  Or

I see the confusion. It would be better to say "uniformly and
pseudorandomly" or
may be just get rid of the word "uniformly" (as you suggest.)

> "Some implementations have..."

 I am not sure if it violates any rules or RFC requirements. Do others on
the list have opinions about this?

> and MAY be set to zero."  I'll leave it to him to explain that choice.

Thanks for pointing out. Will fix this.

> Marcus Dansarie's 3 September comments appear to not have been

Will address these in the next revision.

>
> -- Sam
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 28 Nov 2018 12:36:29 +0200

Hi,

Apologies for the late response, but the datatracker indicates that the
draft is still in WG LC, so here are my comments.

I believe the draft is ready for publication, subject to the comments below.

- The draft is missing a Security Considerations section. There should be
at least a short description of the security considerations. As always, I
suggest to start with something along the lines of: "The security
considerations of time protocols in general are discussed in [RFC7384], and
specifically the security considerations of NTP are discussed in [RFC5905]."
- Regarding the transmit timestamp randomization, please consider the
following change: instead of having a random value for each packet, the
client can generate a random constant value C (just once instead of per
packet), and then for each packet assign the value C+T to the Transmit
Timestamp, where T is the actual value of the timestamp. I believe this
achieves the same goals as per-packet randomization, while guaranteeing
uniqueness and monotonicity. Just a thought.

Cheers,
Tal.

On Wed, Aug 15, 2018 at 11:44 PM Karen O'Donoghue <[email-masked]>
wrote:

> Folks,
>
> This message initiates a two week working group last call for:
>
> NTP Client Data Minimization
> https://datatracker.ietf.org/doc/draft-ietf-ntp-data-minimization/
>
> Please review the referenced document and send any comments to the mailing
> list including your assessment of whether this document is mature enough
> to proceed to the IESG. Please note that these messages of support for
> progression to the mailing list will be used to determine WG consensus to
> proceed.
>
> Please send all comments in by COB on Thursday 29 August 2018.
>
> Thanks!
> Karen and Dieter

---

From: Kyle Rose <[email-masked]>
Date: Wed, 28 Nov 2018 08:24:27 -0500

> uniqueness and monotonicity. Just a thought.

I believe one element of the threat model is to prevent tracking-enabling
linkage across interfaces for mobile clients. Using the same random offset
periodically makes this sort of tracking easier.

Kyle

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Nov 2018 14:21:20 +0100

> uniqueness and monotonicity. Just a thought.

Interesting idea.

What about an attacker who cannot see the client's request in
real-time to be able to spoof a respond, but may see a request or
response later, e.g. from a packet capture? Or perhaps the timestamp
leaks via mode6/7?

That would give the attacker a good approximation of C and it would
be much easier to predict the transmit timestamp in other packets.

-- 
Miroslav Lichvar

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 29 Nov 2018 08:36:21 +0400

> be much easier to predict the transmit timestamp in other packets.
I also agree there.