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

[[e-mail]]

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. 

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

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.

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

I think people are saying that NTPv4 with *available* NTS provides too much leeway to not use security. 

Most importantly, the "lazy" option (the scenario where you make no conscious decision, which I propose the majority of people follow in most cases) currently is to not use security. From a 2020 viewpoint, this simply is backwards, and we need to change it as soon as we can. 

Changing to NTPv5 provides just that opportunity. We can simply standardize that security (with NTS) be enabled. You talked about the potential rollout of NTS, and this would give us the chance to really, really boost (predicted) numbers from <<50% to >>50% of users/machines/messages being secured. I believe we should do this, as anything else would just be a massive waste of opportunity.

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!

Best regards,

Kristof

-----"ntp" <[e-mail]> schrieb: -----

An: "Rich Salz" <rsalz=[e-mail]>, <[e-mail]>, <[e-mail]>
Von: "Ulrich Windl"
Gesendet von: "ntp"
Datum: 10.12.2020 08:23
Kopie: "[e-mail]" <[e-mail]>, "Dieter Sibold" <[e-mail]>
Betreff: [Ntp] Antw: [EXT] Re: NTPv5 draft

    >>> "Salz, Rich" <rsalz=[e-mail]> schrieb am 09.12.2020
um 15:56
in Nachricht <[e-mail]>:
>>  Now, suddenly people talk about some non‑specific issues that have an
>     > unknown solution. Where were you when NTS was designed? And why does
>     > it need to be solved in NTPv5?
>
> NTS was designed to add security features to an existing protocol without
> disrupting it.
>
> NTPv5 should be designed with security built‑in from the beginning.

I think "security" was "built-in" since NTPv3, but:
Was the security srong enough?
Was the security easy to deploy and use?
Did it need shared secrets between different authority zones?

In v4 autokey tried to address some issues, while adding several new

So what should v5 really bring?

Regards,
Ulrich

>
> Miroslav's draft is just an individual viewpoint.  I would be against the WG

> adopting it because the author seems to be opposed to the design requirement

> I just mentioned.
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp 



_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp