Re: [Ntp] NTPv5 draft

[Miroslav Lichvar <[e-mail]>]

On Thu, Dec 10, 2020 at 01:55:53PM +0100, James wrote:
> On 09-12-2020 15:04, Miroslav Lichvar wrote:
> > 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.

Ok. Thanks for clearing that up.

> > 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.

Or, supporting the next version without authentication.

If some implementation wanted to prevent its users from using
unauthenticated NTP, it could support only authenticated NTP and it
could do that with NTPv3, NTPv4 and any future version. The protocol
version doesn't really matter here.

> > 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.

To me it would make sense to have this separate from the NTPv5 on-wire
specification. NTP just needs its data protected. It's up to NTS or a
more general "secure NTP" document to specify how. Currently, NTS
requires TLS1.3 or later. When a major issue is found in TLS1.3 and
that requirement needs to be updated, it's not an issue specific to
NTPv5.

> > > * 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.

Ok.

I think there might be a requirement for the transmit timestamp to be
located close to the end of the protected data to allow an advanced
implementation to interrupt the authentication process, save a fresh
timestamp, and resume the process, in order to minimize the error in
the transmit timestamp. However, this might conflict with a
requirement to have the timestamp at a fixed offset to simplify a
hardware timestamping implementation.

> 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?

The issue with the pool is that there is no single trusted entity, but
a large number of volunteers, so NTS or another "secured NTP" would
have a different meaning from what would be normally expected. It
might be possible to prevent MITM attacks, but it's not possible to
prevent an attacker from joining the pool with their own server.

-- 
Miroslav Lichvar