Re: [Ntp] Antwort: Antw: [EXT] Re: NTPv5 draft

[Miroslav Lichvar <[e-mail]>]

On Thu, Dec 10, 2020 at 11:38:41AM +0100, [e-mail] wrote:
>    It seems to me that the answer is clearly that NTPv5 should natively make
>    available security that is strong (enough), as well as easy to deploy and
>    use.
>    I do not agree with the train of thought that because some users don't
>    strictly need security for their use case, security should be disabled by
>    default.

I asked if the specification should recommend use of authentication,
but Dieter said it's not good enough. I don't think it should require
the use of authentication, but even if it did, it wouldn't change
security of the protocol itself.

I think it's really up to the implementations and their default
configurations. There is not much we can do about it in a protocol
specification.

>    1) First of all, this only makes abstract sense to me as a conclusion if
>    security enabled by default comes at significant cost - and I think we can
>    prevent this from being true, specifically by investing work into support
>    of a "two-step" message format, where all security (and, honestly, most
>    information overall) is only included in the "follow-up" message; then
>    security being enabled really has zero extra cost (apart from everything
>    being more accurate overall).

NTP is used everywhere. Some hardware doesn't have enough
memory/storage to support TLS/NTS. Some computers don't have an RTC or
cannot be assumed to start with correct time to be able to validate
certificates. Symmetric keys may not be practical. 

There are other costs, like the complexity of implementation and
its attack surface. NTS is much more complex than NTP. It's more
likely to have security issues, either in the protocol (TLS) or the
implementation. The threat model with simple unauthenticated NTP is
well understood.

>    2) Second of all, I think these use cases (where users don't need security
>    because they are using NTP in a closed controlled network) are the
>    exception rather than the norm. The majority of NTP traffic is going to
>    happen over the open internet, and security should pretty much
>    unconditionally be used in that scenario.

I agree secure NTP should be the norm, but the protocol shouldn't try
to enforce it.

>    As kind of an aside @Miroslav: I don't think anyone is claiming that
>    NTPv4+NTS has a security issue in the sense that it does not provide
>    adequate security when used (otherwise I really would like to explicitly
>    hear such concerns!).

Rich seems to be saying that if NTPv5 was redesigned for security, it
would be different from NTPv4 or the proposed NTPv5. I don't see how.

NTS in NTP is basically just an AEAD that authenticates and sometimes
encrypts the NTP data. It doesn't matter what it actually is
protecting, right? As long as the protocol allows all data to be
protected, there is no issue with security, e.g. downgrade attacks.
With NTS all security negotiation happens separately over TLS. NTP is
just a payload.

>    Changing to NTPv5 provides just that opportunity. We can simply
>    standardize that security (with NTS) be enabled.

What exactly do you suggest for the document to say?

>    TL;DR: I'm in favor of security being enabled by default in NTPv5 and
>    using NTS to realize that. It presents an opportunity to massively
>    increase the use of security in NTP traffic. If we believe that the cost
>    is too great for some use cases, let us focus our energy on reducing it,
>    instead of letting the opportunity go to waste!

I doubt NTPv5 can change the adoption of NTS. I'd say currently the
biggest issues are the dependency on time for certificate validation
and lack of support in pool.ntp.org. There is nothing NTPv5 can do
about that.

-- 
Miroslav Lichvar