Re: [Ntp] NTPv5 draft

[Philip Prindeville <[e-mail]>]

> On Dec 7, 2020, at 2:19 PM, Hal Murray <[e-mail]> wrote:
> 
> 
> Salz, Rich said:
>> My view is that it is no longer acceptable to design a protocol for
>> deployment on the open Internet that has no authentication or message
>> integrity and that people who disagree are out of consensus.
> 
> That seems like a good general principle, but doesn't seen to fit this example 
> very well.
> 
> What do you mean by "has no authentication"?  Do you mean supports 
> authentication or requires it?  I'll agree if you mean supports, but I assume 
> you mean requires since otherwise we wouldn't be having this discussion.
> 
> Assuming you do mean requires, I'll pay a lot more attention to your argument if you outline a plan for getting the existing user base to demand authenticated time.
> 
> The complexity ratio between a simple non-authenticated NTP client and a client with authentication is enormous.
> 
> With HTTP to HTTPS, there was a lot of incentive for users and servers to upgrade.  Many did financial transactions over the web.  What's the equivalent for NTP?


The 3 principles of Security are CIA: Confidentiality, Integrity, Availability.

How do these apply to NTPv5?  Some examples:

Confidentiality might be making client/server or peering connections unlinked outside of the (binary) relationship.  That was one of the issues with NTPv4; you could query a client to see what server it was talking to, and then spoof that server.

Integrity is protection from mangling packets in-flight, i.e. MITM attacks.  It might also be a chain-of-trust for time source hierarchy going back to a well-known (and explicitly trusted) group of servers who are authentic, which is often called “data pedigree”.

Availability is what it sounds like: the resilience of the service to interruptions, either by being resistant to denial-of-service attacks and single-point-of-failure disruptions, to geographical disruption to harden against network partitioning failures, to simplicity of correct configuration out-of-the-box, etc.

One of the golden objectives of security is “secure by default”: that is, things should be secure as installed by default, and it takes willful action by the administrator or user to explicitly disable this (aka “let him hang himself”).  I don’t see a reason for us to abandon this ideal.

"The complexity ratio between a simple non-authenticated NTP client and a client with authentication is enormous.”

What are you basing that assertion on?

And what about the flip-side of that argument?  What is the opportunity cost of not having that?  Where else does the mitigation end up instead?  Firewalling?  Sanity checking clocks against multiple sources?  Inability to have boot-time PKI integrity because of not being able to check X.509 validity intervals (and the obvious ripple-effect of PKI through other services)?