Re: [Ntp] NTPv5 draft

[James <[e-mail]>]

On 09-12-2020 15:04, Miroslav Lichvar wrote:
> 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?

I have very deliberately avoided solutionising or mentioning NTS thus 
far to focus on the requirements and use-cases. NTPv5 + NTS may be 
appropriate and mitigate downgrade, but what is absent thus far is a 
document describing the protocol which contains normative language about 
the matter.

>> * 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?
Kristof has written a really good description[1] of the issue around 
this which covers this point and a few others.
> 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?
Having authentication enforced in the next version of the protocol does 
not prevent implementations from supporting older versions.
> If it is not an extension, how do you replace it when it's found to be
> insecure?
When it comes to the agility of authentication algorithms, having a 
baseline which implementations should support in addition to an IANA 
registry to allow for new algorithms should be sufficient. When it comes 
to insecurity with the protocol as it functions, this can be mitigated 
ahead of standardisation with thorough review, the use of existing known 
primitives (avoiding "exotic" crypto), formal verification etc.
>> * 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.
To clarify I am not saying that is too long, I am saying that it should 
not be an issue for the use cases I have already described.
>> 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?

I very specifically called out the NTP Pool in my requirements document. 
Could you (or someone else reading) elaborate what specific concerns 
would be around the requirements I have described and their potential 
impact to deployment onto the NTP Pool?

- J

1: https://mailarchive.ietf.org/arch/msg/ntp/9Cz20MvJJaBBJozrhh_Qsvemi4E/