Subject: Re: [Ntp] Draft on using NTS with the pool

From: Watson Ladd <[email-masked]>
Date: Sun, 1 Mar 2020 19:53:00 -0800

On Sat, Feb 29, 2020 at 3:25 AM Marcus Dansarie <[email-masked]> wrote:
>
> Thank you for putting this together!
>
> Your draft proposes a more complicated solution than the one I had
> envisaged. I imagined something like the following.

Thank you for explaining your ideas. I don't think your solution is as
simple as it looks due to some missing peices, while my solution
doesn't seem that complex to me, but I'm open to being convinced
otherwise.

>
> 3. If the client sent a FQDN, the server will pick an NTP server from
> that pool and return cookies for that server along with an appropriate
> NTP Server Negotiation record. If the client sent an IP address (which
> belongs to a server in the pool), the server simply returns cookies and
> NTP Server Negotiation record for that address.

This implies that the servers have key material shared with the pool
for the cookies. That's sort of problematic, especially with key
rotation: you have to all support the same ciphersuites, similar
cookie formats, etc. That adds some complexity that isn't apparent
from the description, and it mean another protocol that NTS
implementations need to interoperate with to transmit the ticket
related data to the pool.

It also increases the load on the pool servers. Round-robin DNS is
very cacheable and easy to serve at high speed, even with DNSSEC.  TCP
based protocols are a bit more heavyweight. This may not be a problem:
I'd appreciate pool operators weighing in on this.

>
> This scheme has the advantage that a pool only needs to run one (or a
> few) NTS-KE servers with certificates for a single (or a few) domain
> names. Each individual server only needs a shared secret with the NTS-KE
> server to support NTS. There is no need to obtain and maintain an
> individual certificate for each server.

With ACME this is straightforward to handle in an automated way.

>
> Kind regards,
> Marcus
>
>
> On 2020-02-28 21:30, Watson Ladd wrote:
> > Hello,
> >
> > I've uploaded https://datatracker.ietf.org/doc/draft-ladd-nts-for-ntp-pool/
> > which contains a putative mechanism for using NTS with the NTP pool.
> >
> > I'd appreciate comments: there is a lot to think through in this, but
> > it's important to get NTS adoption. Definitely the draft is in rough
> > shape, but sooner seemed better than never.
> >
> > Sincerely,
> > Watson Ladd
> >
> > _______________________________________________
> > ntp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ntp
> >
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Hal Murray <[email-masked]>
Date: Sun, 01 Mar 2020 22:06:04 -0800

[email-masked] said:
> This implies that the servers have key material shared with the pool for the
> cookies. That's sort of problematic, especially with key rotation: you have
> to all support the same ciphersuites, similar cookie formats, etc. That adds
> some complexity that isn't apparent from the description, and it mean another
> protocol that NTS implementations need to interoperate with to transmit the
> ticket related data to the pool. 

The draft has a recipe for keeping cookies in sync once you have things setup. 
 I don't know if anybody has implemented it.  I didn't because we didn't need 
it - we have the KE server and NTP server using those cookies in the same 
address space.  The text looked clear enough that I was pretty sure it would 
work.

If we decide to use some other protocol for keeping cookies in sync, it 
doesn't need a RFC level description, just a page on the pool server web site.

-----------

If there is a centralized NTS-KE server, then there must be some secret shared 
between the KE server and NTP server that is using those cookies.  Is that one 
master key, or a separate key for each server?  A separate key makes the 
server signup process slightly more complicated, but that doesn't seem like a 
serious burden.  That process already knows how to grab a password for the 
server admin.

Note that the single master key approach doesn't work.  Well, it works, but it 
doesn't provide any security.  The bad guy can sign up a server in the pool to 
get the secret.  After that, he can MITM any NTP requests to pool servers.

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Mar 2020 13:30:10 +0100

> shape, but sooner seemed better than never.

I think at least on some platforms dependency on SRV and DNSSEC may be
very problematic. I suspect in many cases the NTS client would need to
have its own DNS client in order to get the SRV record and be sure
that the DNS response was validated.

Are there any other protocols that depend on DNSSEC? The few that I'm
familiar with, like SIP or XMPP, don't rely on DNSSEC (certificates
are for the original name, not those from SRV record).

I'm wondering if it would make sense to specify a "redirect" NTS-KE
record, which would tell the NTS-KE client to connect to a different
NTS-KE server without giving any cookies. The client would remember it
for some specified time to decrease the load on the server. This would
be closer to DNS over TLS rather than DNSSEC.

-- 
Miroslav Lichvar

---

From: Marcus Dansarie <[email-masked]>
Date: Mon, 2 Mar 2020 21:26:36 +0100

> doesn't seem that complex to me, but I'm open to being convinced

The main differences between our respective proposals is that one
requires each NTP server to run its own NTS-KE server and the other
allows for a single or a few NTS-KE servers to service an entire pool of
thousands. Both solutions have their own distinct advantages and
disadvantages. Which is best for a particular pool is likely dependent
on its organization and infrastructure.

To begin with, we should probably make sure we agree on the problems
that need to be solved. I see two:

1. A client which is configured to use an NTP server (which may or may
not belong to a pool) should be able to configure itself to use NTS with
that server, without user interaction.

2. Large pools of NTP servers should be able to deploy NTS in a seamless
manner.

> related data to the pool.
Yes, this is the main drawback. If NTP servers in the pool run (for
example) three different NTP implementations with NTS support, the pool
would likely have to support three different cookie formats. There are
two solutions to this: Either the pool mandates a specific cookie format
or it runs three different NTS-KE servers.

I am less worried about key rotation. Either the NTP servers generate
new keys and submits them to the pool or the pool generates new keys and
makes them available to the NTP server. This could be done through some
HTTPS GET or POST mechanism.

> I'd appreciate pool operators weighing in on this.

The load on a pool NTS-KE server would not be very high. In the normal
case, a client would only need to perform a single NTS-KE handshake for
each NTP server it uses. All existing NTS protected NTP sessions would
continue to work even if the NTS-KE server becomes unavailable for some
reason.

> With ACME this is straightforward to handle in an automated way.
Indeed. I mainly see administrative and organizational problems here.
Are we sure the owners of example.org are comfortable with possibly
unknown persons being assigned certificates for subdomains?

Kind regards,
Marcus