Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)

Miroslav Lichvar <> Mon, 12 April 2021 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 021A93A238D for <>; Mon, 12 Apr 2021 08:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=0.28] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W8GmuD0k9SvA for <>; Mon, 12 Apr 2021 08:48:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F148D3A236A for <>; Mon, 12 Apr 2021 08:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1618242524; 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=nTn5lnOBLreDRHRMyxYGyZJu4QVONVw6Hqo7DHjp56g=; b=fNCkuwG6+mp+0+Am07jon+qiNDV+9DO79sQRGTu7hOpyt5OH5vkiAlOlzS2pPLN8Nlyg/e 28uhjyK1ekEzmT+EVxuzTvcjysavQkokJzCCQBsP+W4KP+/1vYnO8OtJO2zTF/GmyZnjsm 5LS/DsWcgAYV55VZHplEtNpr1JP73i0=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-122-IJMAY7sGNsWKcmmnLbCZcg-1; Mon, 12 Apr 2021 11:48:40 -0400
X-MC-Unique: IJMAY7sGNsWKcmmnLbCZcg-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38AE31856A63; Mon, 12 Apr 2021 15:48:39 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 8D94350DD4; Mon, 12 Apr 2021 15:48:38 +0000 (UTC)
Date: Mon, 12 Apr 2021 17:48:36 +0200
From: Miroslav Lichvar <>
To: David Mills <>
Cc: NTP WG <>
Message-ID: <YHRr1IhY7Xg8+uo2@localhost>
References: <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 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] Protocol and Security Enhancements for the Network Time Protocol (NTP)
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, 12 Apr 2021 15:48:52 -0000

On Sun, Mar 28, 2021 at 01:36:44PM -0400, David Mills wrote:
> Recent
> discussion in the newsgroup has centered on dramatic security mechanisms and
> exotic services for ntp version 5, but less attention has been on the
> underlying onwire protocols evolved from current NTP version 4.

> URL:

I didn't see any comments about this document. Others here would
know better how this works as a replacement of the old Autokey. I'll
just point out few non-crypto things that didn't seem quite right to

The protocol doesn't prevent amplification attacks using the cookie
response. The document claims that rate limiting prevents such
attacks, but I don't think that is true. Rate limiting is not a
security mechanism. It actually creates other security issues. The
server has a limited amount of memory. Attackers can avoid rate
limiting by using more addresses than the server can remember. That's
easy if the victim is using IPv6.

It doesn't have a fully random nonce in addition to the transmit
timestamp. It claims that transmit timestamps are not predictable
while it recommends to not use the data minimization.

The cookie seems to be constructed just from a secret key and client
address, without a nonce.

The handshake in the symmetric mode seems to be still vulnerable to
off-path DoS attacks.

In the broadcast mode the transmit timestamp is used as a sequence
number, which means the server cannot have a backward step. It doesn't
have a mechanism to protect against delay attacks. (That was a goal
in earlier NTS designs.)

The described parser detects legacy MACs by checking whether the
length field of an extension field is zero. I guess that was meant to
be the type of the field? That would work only with key IDs below

It claims that NTS doesn't support interleaved mode. How could it, are
those two not at different layers? NTS+xleave definitely works for me.

Miroslav Lichvar