Re: [Ntp] Draft extension NTS for pools

[David Venhoek <[e-mail]>]

Thank you for the feedback, below inline my responses to a number of points

On Sun, Dec 24, 2023 at 6:36 AM Hal Murray <[e-mail]> wrote:
>
>
> I think the pool as we know it and security are incompatible.  The problem is
> one of trust.  If you have a large collection of volunteers, there is no way
> to know that they are all good guys.  NTS can ensure that you are talking to a
> pool server, but not that the operator of that system is a good guy.

True, however there is still some value in ensuring you are talking to
a specific pool server from a security point of view.

> I could imagine a pool run with a restricted membership.

This is one of the scenarios we are considering when moving this more
towards operational.

>  ...
>
> ---------
>
> Your draft is well written.  I think I could implement from it without much help.
>
> I think it needs a big warning about trust and the current pool.

Feel free to provide text for a concrete suggestion on this.

> Section 5: Pool authentication
> I don't understand
>   To discourage misuse, ...
> What sort of misuse do you have in mind?  What could a bad guy do if he gets cookies for an arbitrary key?

The honest answer here is that we don't have a concrete attack that
could exploit this. However, we felt very uncomfortable to allowing
arbitrary clients to do this, as it is something that isn't possible
in the original design of NTS.

As for the misuse, if this were open for arbitrary clients, somebody
could implement a client that requests cookies for itself but still
chooses the key manually. This is a bad idea because it opens you up
to potentially choosing bad keys (insufficient randomness, that sort
of thing).

>   ... MUST authenticate clients using the Fixed Key Request
>   record using TLS client certificates.
>
> At first glance, that seem overly strong.  Yes, client certificates are a good way to authenticate.  Why isn't filtering by IP Address good enough?  It might be simpler to implement with firewall rules.  But that's not good enough if you are worried about MITM attacks.

Filtering by IP isn't enough, as authenticity of IP addresses isn't
guaranteed. Also, IP addresses as identities are less stable than may
be desirable for a server. We chose to specify TLS client certificates
specifically because that avoids specifying our own authentication
scheme, and ensures all servers support the same mechanism.

On the whole, I think I am open to relaxing these particular
requirements to a SHOULD, but we made these particular choices out of
an abundance of caution. Note that they don't impact performance much
since these connections can be persistent for decent amounts of time.

>
> Section 6.5. NTP Server Deny
>
> > A client MAY send multiple of these records if desired. The data in the
> > record SHOULD match that given through an NTPv4 Server Negotiation received
> > in an earlier request from the same NTS Key Exchange server.
>
> I think this area needs work.  I need to be able to avoid servers that I got some other way that also happen to be in the pool.
>
> And you might have multiple servers for load sharing so "the same" gets complicated.

I agree that this isn't a perfect solution, though to be honest I
don't see a good way to do better. For avoiding servers you get in a
different way, these may be known to you under a different name than
the pool knows them by, so avoiding those via these records may or may
not work. That is the primary reason for the SHOULD here (ensuring you
provide a name knowable to the pool).

"the same" was intended here in the logical sense of the word, so
multiple servers for load sharing would still be "the same" for the
purpose of this clause, but maybe we should clarify that some more.