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

Miroslav Lichvar <> Mon, 14 December 2020 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3EF43A07D3 for <>; Mon, 14 Dec 2020 04:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5SH6R7utZ02I for <>; Mon, 14 Dec 2020 04:31:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41BE93A1047 for <>; Mon, 14 Dec 2020 04:31:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1607949096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uGWA72WrDg3orOGYE2sbnjyjv60BsTUyO5ePImdLHJQ=; b=dqy2s7oOzaq+c+VEwg+ejlyd2Ym4exgAv0W5l5B30Otaum3E11q05vL+eB2r2k24Kt862w 9coaX6QllnhFTdnkBK+o7FYmhOd663f0WbdBuwRGQurCon+JBkiNwHTdS8iv70+JcWL2Px 9L1Dn8y7EgGbTU7HkxGR1Cy/eX5hrQY=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-466-Q9yjgc_tN6S6TtQSUB01hQ-1; Mon, 14 Dec 2020 07:31:31 -0500
X-MC-Unique: Q9yjgc_tN6S6TtQSUB01hQ-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26DE5800D55; Mon, 14 Dec 2020 12:31:30 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id C48B73480B; Mon, 14 Dec 2020 12:31:28 +0000 (UTC)
Date: Mon, 14 Dec 2020 13:31:27 +0100
From: Miroslav Lichvar <>
Cc: Ulrich Windl <>, "" <>, Dieter Sibold <>,, Rich Salz <>
Message-ID: <20201214123127.GE2540645@localhost>
References: <20201208150725.GX2352378@localhost> <> <20201209083800.GY2352378@localhost> <> <> <> <> <> <> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] Antwort: Antw: [EXT] Re: NTPv5 draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Dec 2020 12:31:39 -0000

On Thu, Dec 10, 2020 at 11:38:41AM +0100, 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

>    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 There is nothing NTPv5 can do
about that.

Miroslav Lichvar