Subject: Re: [Ntp] WGLC: draft-ietf-ntp-port-randomization

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Sep 2020 12:25:00 -0300

Hello, Kristof,

On 27/8/20 07:41, [email-masked] wrote:
> Hello,
> 
> here is a short list of typos and other minor (easily correctible) 
> issues that I found:
> - Section 3.1, second paragraph: "this considerations" (fix 
> singular/plural discrepancy)

Will do.

> - Section 7: "However, the NTP specification has traditionally followed 
> a pattern of employing common settings and code even when not strictly 
> necessary, which at times has resulted in negative security and privacy 
> implications (see e.g. [I-D.ietf-ntp-data-minimization])." Subjectively, 
> I find the tone of this unnecessarily negative, and think the document 
> might be better off if the sentence is dropped and the sentence 

Could you pleas clarify which part you deem as being overly negative? 
And, also, which part you suggest to leave off?

> afterward updated in order to fit the context but remain more objective 
> (also, that sentence might benefit from being split in two by a period 
> before "[such] unnecessary usage").

    " The use of the NTP service port
    (123) for the srcport and dstport variables is not required for all
    operating modes. Such unnecessary usage comes at the expense of
    reducing the amount of work required for an attacker to successfully..."

?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Sep 2020 12:15:57 +0530

Hi WG,

I support the publication of this I-D. The document is well written
and clear. Just a few suggestions -

~ Suggest to add a clear reference for {srcaddr, srcport, dstaddr,
dstport, keyid} as Section 9.1 of RFC 5905.
~ There are different terms used for the port - service/well-known
port, service port, well-known/service port and the RFC 5905 called it
just the NTP port number. Is it possible to be consistent?
~ Update metadata to "Updates: 5905 (if approved)" - you only need the
RFC number.
~ Update requirement language to include RFC 8174
~ Is the NOTES in section 4 part of the replacement text of RFC 5905?
I ask because there could be confusion on the reference to Section 3.2
to this document or the RFC 5905.

Thanks!
Dhruv

On Thu, Aug 27, 2020 at 7:53 AM Karen O'Donoghue <[email-masked]> wrote:
>
> Folks,
>
> This email starts a two week WGLC on:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/
>
> Please respond on the mailing list (keeping the subject line intact) with any comments you have on this document. Please also indicate your opinion on whether or not this document is sufficiently mature to advance to publication.
>
> Regards,
> Karen
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Sep 2020 09:26:37 +0200

>>> Fernando Gont <[email-masked]> schrieb am 06.09.2020 um 17:25 in
Nachricht <[email-masked]>:
>> ‑ Section 3.1, second paragraph: "this considerations" (fix 
>> ‑ Section 7: "However, the NTP specification has traditionally followed 
>> implications (see e.g. [I‑D.ietf‑ntp‑data‑minimization])." Subjectively, 

To me it sounds like a justification for ntp-data-minimization, but the logik
is broken:
You can't say ntp-data-minimization is needed because of what it does. You
should "name the child" (security problems).

>     reducing the amount of work required for an attacker to
successfully..."

Also: ?

> 
> Thanks!
> 
> Regards,
> ‑‑ 
> Fernando Gont
> SI6 Networks
> e‑mail: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 08:23:48 -0300

Hi, Ulrich,

On 8/9/20 04:26, Ulrich Windl wrote:
[...]
> should "name the child" (security problems).

I'm a bit lost here. The text does say "which at times has resulted in 
negative security and privacy implications".

Should we remove the reference to I‑D.ietf‑ntp‑data‑minimization ? 
Something else?

>>      reducing the amount of work required for an attacker to

FWIW, this was suggested tweak in response to Kristof's comment...

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Sep 2020 11:19:14 -0300

Hello, Dhruv,

Thanks a lot for your feedback! In-line....

> dstport, keyid} as Section 9.1 of RFC 5905.

I've modified the text as:

"Many of these attacks require the attacker to guess or know at least a 
target NTP association, typically identified by the tuple {srcaddr, 
srcport, dstaddr, dstport, keyid} (see section 9.1 of [RFC5905])."

ok?

> just the NTP port number. Is it possible to be consistent?

Yep. Will do. For the most part, will use "well-known port" or "NTP 
well-known port" (where necessary).

> ~ Update metadata to "Updates: 5905 (if approved)" - you only need the

Good grief! Done.

> ~ Update requirement language to include RFC 8174

Done.

> to this document or the RFC 5905.

Good grief! The NOTES are part of the replacement text. The reference to 
Section 3.2 is to the section in this document -- although if this is 
meant to be a patch (as in "is replaced with the following text") then 
it would imply a reference to RFC5905, and that'd be an error.

So.. how about tweaking the text as:

"The choice of whether to randomize the port number on a per-request or 
a per-association basis is left to the implementation, and should 
consider the possible effects on path selection along with its possible 
impact on time measurement."

At the end of the day, that's what Section 3.2 talks about. And that 
would avoid the ambiguity.

Alternatively, one could tweak the text as:

"...      NOTES:
          The choice of whether to randomize the port number on a per-
          request or a per-association basis is left to the
          implementation, and should consider, among others, the
          considerations discussed in Section 3.2 of
          [RFC_THIS_DOCUMENT]."

but I think the previous alternative is better.

Thoughts?

Thanks!

Regards,