Subject: [Ntp] NTP pool and NTS brainstorming

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Feb 2020 15:36:40 -0800

Dear all,

I think the pool can support NTS quite easily by extending the type of
record returned. Instead of an A record, it can return a SRV record
with the FQDN of a server that supports NTS. The server will have a
cert for the FQDN. With DNSSEC this provides authenticity: the pool
indicates the server, and then TLS confirms that the correct server is
being talked to. We'll already get a SRV record allocated since the
registry is the Service Name and Port Number registry.

Challenges to this technique are the need for a different record type
to be interpreted, but it doesn't add much work to the job of the DNS
servers answering queries for the pool. I think this is easier than
proposals involving a shared key (administrative nightmare).

Sincerely,
Watson

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Feb 2020 01:11:11 +0000

Look ar https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03

---

From: Hal Murray <[email-masked]>
Date: Fri, 28 Feb 2020 00:22:08 -0800

watson=[email-masked] said:
> I think the pool can support NTS quite easily by extending the type of record
> returned.

I think something like that can be made to work.  But does NTS make sense in 
the context of a pool?

The problem is trust.  Anybody can add their server to the pool.  If I trust 
the person running the pool to run it as he describes, why should I extend 
that trust any of the servers in the pool?

We should have put a sentence or paragraph pointing out that trust step in the 
RFC.

-- 
These are my opinions.  I hate spam.

---

From: Dieter Sibold <[email-masked]>
Date: Fri, 28 Feb 2020 10:10:37 +0000

I had a talk with Christer in Singapore in which he explained to me a similar approach. Basically, it would require to pools to send SRV records. I'm sure he can contribute to this discussion.

Dieter

Am 28.02.20, 00:37 schrieb "ntp im Auftrag von Watson Ladd" <[email-masked] im Auftrag von watson=[email-masked]>:

    Dear all,

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

---

From: Marcus Dansarie <[email-masked]>
Date: Fri, 28 Feb 2020 15:31:30 +0100

I briefly mentioned the idea of using SRV records to allow clients to
find NTS-KE servers autonomously back in November 2018. The idea was
that a client which has been configured with just the domain name of an
NTP server could look for a NTS-KE SRV record associated with that
domain name. That way, it would automatically configure itself for
NTS-KE without user interaction. I still believe this is a good idea
that would speed up the adoption of NTS.

> that trust any of the servers in the pool?

You are right that NTS does not extend any trust to the servers in a
pool, but NTS still makes sense in that application. This is mainly
because it provides protection against MITM attacks. They are quite
common in practice, since many ISPs MITM all NTP traffic from their
networks.

> We should have put a sentence or paragraph pointing out that trust
step in the

I think a new draft that describes SRV records for NTS-KE and provides
guidelines for the use of NTS in NTP pools would be of benefit.

Kind regards,
Marcus

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Feb 2020 14:56:36 +0000

Again, I encourage folks to look at the new service draft.  Previously link I posted was out of date.
https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Feb 2020 07:45:22 -0800

> https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00

I have glanced at it but I'm not sure that we need the additional
complexity over SRV. Maybe there are limitations I'm not thinking of.  I'll
throw a draft up if I get to it this weekend, but might not happen.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Feb 2020 22:36:26 +0000

*   I have glanced at it but I'm not sure that we need the additional complexity over SRV. Maybe there are limitations I'm not thinking of.  I'll throw a draft up if I get to it this weekend, but might not happen.

I thought you were talking about new records types in the SRV.