Re: [Ntp] [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity

Benjamin Kaduk <> Mon, 15 February 2021 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D93E3A0EDB; Sun, 14 Feb 2021 17:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WdzCMiIGb7zj; Sun, 14 Feb 2021 17:11:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85A5E3A0EE1; Sun, 14 Feb 2021 17:11:39 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 11F1BRgj008712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Feb 2021 20:11:32 -0500
Date: Sun, 14 Feb 2021 17:11:27 -0800
From: Benjamin Kaduk <>
To: tom petch <>
Cc: Dhruv Dhody <>, NTP WG <>,,,, Dieter Sibold <>,
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Ntp] [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity
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, 15 Feb 2021 01:11:42 -0000

Hi Tom,

On Tue, Feb 09, 2021 at 10:23:57AM +0000, tom petch wrote:
> On 08/02/2021 17:05, Dhruv Dhody wrote:
> > Hi Tom,
> >
> > Thanks for your detailed review. Lets discuss the security first -
> >
> > On Mon, Feb 8, 2021 at 6:07 PM tom petch <> wrote:
> >>
> >> This is my second response to this Last Call, about a possible security
> >> issue.
> >>
> >> RFC8573 seems clear that MD5 must not be used to effect security for NTP
> >> but this I-D imports iana-crypt-hash which allows MD5 without any
> >> restriction, so is MD5 allowed or not?
> >
> > Good question. While it is easy to restrict the use of MD5 by adding a
> > must statement, I want to check if it is a good idea. The YANG model
> > is written in such a way that it supports older versions of NTP as
> > well. Would barring MD5 configuration be an issue if there are older
> > implementations in the network still? I think perhaps adding a warning
> > in the description is a good idea. I did a quick search and dont see
> > other YANG models doing a check either. Would be good to get some
> > guidance on this.
> Dhruv
> After many years, Security (AD, secdir, advisor) still have the power to 
> surprise me but I would still be surprised if Security were happy with 
> an I-D which places no constraint on MD5 when the IETF has published RFC 
> deprecating its use and NTP has RFC8573 which specifically deprecates it.
> Yet Security may not realise this from reading this I-D since the 
> unrestricted use of MD5 is not immediately apparent so my post was aimed 
> at bringing this to the attention of Security.  As to whether this needs 
> a note in Security Considerations or enforcing by YANG or both I am less 
> clear on - that is up to Security.  If the YANG is to deprecate it, then 
> the features in ianach make that possible.
> Whether or not MD5 is widely used in the field is irrelevant.  The IETF 
> consensus it to deprecate its use and I am sure that the IESG will want 
> this I-D to do just that.

Thanks for flagging the issue; it's good to have many eyes looking out for
these things.

That said, I think recent practice has been to not take a strict hard line
that MD5 cannot be used ever, and that non-cryptographic uses for legacy
compatibility can be retained, when accompanied by a disclaimer that the
use of MD5 is not for cryptographic purposes and that MD5 is not a secure
cryptographic hash function.

There is an example of this buried in my remarks at that
resulted in the text now found at .