Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Daniel Franke <[e-mail]>]

On Tue, Jun 1, 2021 at 3:43 AM Marius Rohde <[e-mail]> wrote:

> Firstly, from a security point of view, every network that is not just
> accessible physically or logically by privileged persons, processes or
> computer systems should be considered insecure. And that is not just
> true for the Internet ;). To rely only on firewalls is a flaw in the
> design of the infrastructure. You should always implement as many lines
> of defense as feasible. Additionally, think of misconfigurations,
> insiders, or everything you have not been thinking about.
> Do not get me wrong, I know that it is always a question of risk
> management how many time and resources an attacker has to invest to
> break the system. I think our part is not to decide which risk/security
> goals people should achieve but to give them well documented
> opportunities to get the security level they need.

To illustrate any gap between NTS4NTP/PTP and NTS4UPTP security, you
already have to assume some things that are not good security practice
to assume in general, because under conservative assumptions they both
provide half-RTT security and nothing better. Please be more concrete
about what adversary powers you think NTS4NTP/PTP falls short on but
NTS4UPTP adequately supports. In your first sentence I think you might
be getting at "run an unprivileged process from a privileged network
position", but NTS4NTP/PTP is already fine there because unprivileged
processes can't spoof network addresses that don't belong to the host,
bind to low-numbered ports, or bind to ports that are already in use
by other users. "Misconfigurations" in general are not something we
can possibly support, since misconfigurations could include turning
off NTS; if you think there are particular classes of
misconfigurations we need to support, please characterize the
boundaries of those classes.

> IMHO NTS4NTP/PTP is currently not on the same level of security like
> NTS4UPTP because it does not provide the security to adequately ban the
> amplification monster PTP nor the guaranteed PTP precision in the
> borders of NTP.

I've already described how to mitigate DDoS amplification without the
need for key exchange. To require the user to set up and maintain a
PKI just to accomplish this is unnecessary and silly.

> In addition, I am not convinced that NTS4NTP/PTP would make it easier to
> setup a PTP infrastructure than to use NTS directly built in the
> protocol from a user’s point of view.

Clearly it's easier today, since the tools for NTS4NTP/PTP already
exist, and NTS4UPTP doesn't. I never claimed NTS4NTP/PTP would be
easier for the user in a hypothetical future where both approaches
have been fleshed out thoroughly and support for them is ubiquitous;
in that world the two seem about equally easy to use.

> I do not have a crystal ball and cannot say what will be tomorrow but to
> say - today people are not using it over the internet, so we need no
> additional security - is not a valid argument.

Good thing, then, that that isn't at all what I'm arguing!