Re: [Ntp] NTPv5 draft

[Miroslav Lichvar <[e-mail]>]

On Wed, Dec 09, 2020 at 03:12:52PM +0100, James wrote:
> I was hoping that the requirements document[1] I had briefly written, along
> with the several[2] emails I have sent to you and the list[3] describing
> more of my use cases and needs as well as those of others believed to be
> relevant would have sufficiently answered this question already.

I had read your draft (thanks for writing it!) and your emails, but
it's not clear to me. I thought my proposal was meeting the
requirements.

> To
> summarise, I believe the core protocol needs to offer downgrade-resistant
> authentication as:

Is NTPv4+NTS or the NTPv5 I'm proposing + NTS not resistant to
downgrade attacks? Are you refering to some TLS issue? What changes
would you suggest to fix it?

> * Securing NTP via extensions, IPSec etc adds additional cost and
> integration complexity as well as an increased risk of downgrade or
> misconfiguration in deployments;

I don't understand this part at all. An NTP authentication mechanism
in an extension field is very different from IPSec.

If NTP wasn't secured with an extension, how would it prevent
downgrade or misconfiguration? Are you considering a bug where the
client forgets to check if the packet is authenticated? Do you expect
NTP implementations to drop support for older NTP versions?

If it is not an extension, how do you replace it when it's found to be
insecure?

> * And that the computation/latency costs that would incur would be
> acceptable and reduced as implementations improve over time.

It takes few microseconds to authenticate an NTP packet with NTS. Are
you saying that's too long? What is your use case? The delay is
comparable to the typical error of a transmit timestamp. In the
interleaved mode it doesn't matter how long it is, it's compensated.

> What are the use cases you are considering, and what limitations do you
> think that providing authentication will impose on the protocol that would
> not make it suitable for them?

I'm trying to consider all the use cases I've heard about. That
includes isolated networks and various hardware implementations with
different limitations, where it is not possible or not practical to
implement TLS/NTS.

Don't forget about pool.ntp.org. Do you not want NTPv5 to be supported
there?

-- 
Miroslav Lichvar