Subject: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools)

From: [email-masked]
Date: Wed, 30 Aug 2017 08:50:42 +0200

Hi all,

thanks to Yuanlong, Paul and Greg for their feedback.
In response to Paul's feedback:

1./4.) (Covers Yuanlong's feedback as well):
 I second the notion that we should adapt as much of the normative 
language in the document as possible into requirements language as per RFC 
2119.

3.)
I like the current name "cookie placeholder" over the suggestion "cookie 
request", simply because the former is more descriptive with regard to the 
same-length notion.
I do, however, not have a strong opinion on this.

5.) (Also goes to an issue raised implicitly by Harlan & Dave)
Concerning the NTP pools passage, I think there is something to the raised 
concerns, but I would approach the issue via the phrasing of the 
paragraph.
I suggest instead of simply saying "pool operators" or "pools" (which does 
silently imply ALL of them). we move to saying "some pool operators / 
pools", since the problem persists even if it does not concern all 
instances.
My text suggestion is:

        "[...] A more important matter, however, is that not all pool 
operators have procedures for establishing and maintaining trust in their 
members. 
        Pools in existence as of 2017 are often volunteer-run, some of 
them with minimal requirements for admission and/or with no organized 
effort to monitor pool servers for misbehavior. [...]"

I think this text does the same thing for the conclusion (in general, 
using pools with NTS is a bad idea), but hopefully more people will view 
it as factually correct.

Best regards

---

From: Paul Gear <[email-masked]>
Date: Wed, 30 Aug 2017 19:40:26 +1000

On 30/08/17 16:50, [email-masked] wrote:
>
> 3.)
> I like the current name "cookie placeholder" over the suggestion
> "cookie request", simply because the former is more descriptive with
> regard to the same-length notion.

I don't have a strong opinion on this either; I just found that on
initial reading it made more sense to think of it in this way -
especially when viewed in light of the fact that the number of cookie
placeholders normally indicates to the server the number of missed
replies since the last exchange.

> Concerning the NTP pools passage, I think there is something to the
> raised concerns, but I would approach the issue via the phrasing of
> the paragraph.
> I suggest instead of simply saying "pool operators" or "pools" (which
> does silently imply ALL of them). we move to saying "some pool
> operators / pools", since the problem persists even if it does not
> concern all instances.
> My text suggestion is:
>
> operators have procedures for establishing and maintaining trust in
> their members.

Is there more than one pool?  I'm only aware of pool.ntp.org, which is
volunteer-run and has minimal requirements for admission, but certainly
monitors its members.  Results of this monitoring are publicly available
at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine:
http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b).  I think this
qualifies as "an organised effort to monitor pool servers for misbehavior".

> using pools with NTS is a bad idea), but hopefully more people will
> view it as factually correct.

I would hope that this conclusion is specifically what NTS is aiming to
avoid.  With respect to NTS' privacy/unlinkability aims, I would have
thought that the most common use case would be with garden variety
phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP
pool.  Aiming for a system which works with the pool would bring the
greatest privacy benefit to the greatest number of users.  (And I would
argue that the pool requiring NTS support from participants could become
a useful tool in driving NTS adoption, once the questions about
certificate validation are answered.)

Regards,
Paul

---

From: Paul Gear <[email-masked]>
Date: Wed, 30 Aug 2017 19:40:26 +1000

Regards,
Paul

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

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:42:39 +0200

Hi Paul, thanks for your input. Please, see my replies below.

Dieter

"ntp" <[email-masked]> schrieb am 30.08.2017 11:40:26:

> Von: Paul Gear <[email-masked]>
> An: [email-masked]
> Datum: 30.08.2017 11:40
> Betreff: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp 
> (Requirements Language / NTP Pools)
> Gesendet von: "ntp" <[email-masked]>
> 

I acknowledge that the usage of pools would be very helpful. And  don't 
understand me wrong. I like the pools and honor there work. But I still 
see problems with the trust of a pool. As far as I know pools it is pretty 
easy to become a member of a pool. Therefore, a malicious NTP-Server can 
become a member of the pool, he can perfectly synchronized to UTC and 
still send me false timestamps. The monitoring done by the ntp pool 
volunteers  is great but it is not sufficient to establish trust in the 
pool members. That would be different if the pool representatives could 
guarantee that all of there members are trustworthy. Currently, I think 
this is not possible. But perhaps I'm wrong. I'd like to learn better.

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:42:39 +0200

Dieter

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 11:43:38 -0400

> qualifies as "an organised effort to monitor pool servers for misbehavior".

I hadn't seen this. I'll drop that phrase.

> certificate validation are answered.)

Oh, certainly, I eventually want us to get us to a point where you can
just put something like 'nts-pool.ntp.org' in your config and get
NTS-secured time. The purpose of that section is just to highlight the
work that still needs doing before we can get there.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 11:43:38 -0400

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 11:58:46 -0400

New language for that section:

	  Additional standardization work and infrastructure
	  development is necessary before NTS can be used with public
	  NTP server pools. First, a scheme will need to be specified
	  for determining what constitutes an acceptable certificate
	  for a pool server, such as establishing a value required to
	  be contained in its Extended Key Usage attribute, and how to
	  determine, given the DNS name of a pool, what Subject
	  Alternative Name to expect in the certificates of its
	  members. Implementing any such specification will
	  necessitate infrastructure work: pool organizers will need
	  to act as certificate authorities, regularly monitor the
	  behavior of servers to which certificates have been issued,
	  and promptly revoke the certificate of any server found to
	  be serving incorrect time.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 11:58:46 -0400