Re: [Ntp] NTPv5 draft

[James <[e-mail]>]

I'm also interested in NTPv5. Based on my current use cases, the 
protocol having downgrade-resistant authentication as a core function of 
the protocol would simplify my deployments and improve the overall 
security of them and that deploying extensions, IPSec or other measures 
increase risk and complexity. Other use cases I have outlined[1] may 
also benefit as well. As an example, consider that several issues[2] (#5 
and #8) focus around the use of IP addresses in refid - if the 
identifier for a server was replaced with a identifier tied to a 
certificate or signature that was used as part of negotiating the 
primitives to provide authentication, this could theoretically address both.

As for your comment earlier around browsers defaulting to HTTP not 
HTTPS, consider that many browsers only support HTTP/2 with TLS and not 
"h2c", and that HTTP/3 requires QUIC (thus requiring TLS exclusively) - 
if implementations and deployments wish not to use TLS with HTTP, their 
only choice is to use older versions of the protocol.

- J

1: 
https://tools.ietf.org/html/draft-gruessing-ntp-ntpv5-requirements-00#section-2

2: https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

On 07-12-2020 15:34, Miroslav Lichvar wrote:
> On Mon, Dec 07, 2020 at 03:09:15PM +0000, Salz, Rich wrote:
>>>     NTS just become a thing. Forcing people to NTS by removing
>>      unauthenticated NTP from NTPv5 won't work.
>>
>> We're not forcing anyone.  Folks who want unauthenticated NTP can stay on NTPv4.
> None of the issues that have been proposed for fixing in NTPv5 are
> related to authentication. Why should folks interested in NTPv5 be
> forced to use/implement authentication if they are perfectly ok with
> unsecured NTP?
>
> If you feel NTP needs a new name for "secure NTP", specify NTPS in a
> separate document. You can apply it to NTPv5, NTPv4 and even NTPv3 if
> you allow authentication with a symmetric key. This has nothing to do
> with NTPv5 specifically.
>