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

Benjamin Kaduk <kaduk@mit.edu> Mon, 15 February 2021 23:49 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF83A1327; Mon, 15 Feb 2021 15:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6xOOzDafDUX; Mon, 15 Feb 2021 15:49:01 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13B33A1326; Mon, 15 Feb 2021 15:49:00 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11FNmm49023478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Feb 2021 18:48:53 -0500
Date: Mon, 15 Feb 2021 15:48:48 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: tom petch <daedulus@btconnect.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, NTP WG <ntp@ietf.org>, last-call@ietf.org, draft-ietf-ntp-yang-data-model@ietf.org, ek.ietf@gmail.com, Dieter Sibold <dsibold.ietf@gmail.com>, ntp-chairs@ietf.org
Message-ID: <20210215234848.GM21@kduck.mit.edu>
References: <161195994417.2651.6499166797756243533@ietfa.amsl.com> <60212265.6020204@btconnect.com> <CAB75xn7tXa1BCHd=KFR9DC=+bA01R1A+X2M4oUbrF-YLx8ExJA@mail.gmail.com> <602262BD.3050708@btconnect.com> <20210215011127.GA21@kduck.mit.edu> <602AB12E.9040701@btconnect.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <602AB12E.9040701@btconnect.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA>
Subject: Re: [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2021 23:49:04 -0000

On Mon, Feb 15, 2021 at 05:36:46PM +0000, tom petch wrote:
> On 15/02/2021 01:11, Benjamin Kaduk wrote:
> > 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 <daedulus@btconnect.com> 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
> > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ballot/ that
> > resulted in the text now found at
> > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-29#section-11.6 .
> 
> Ben
> 
> Thank you for noticing:-)
> The -10 that I reviewed had
> - MD5 is used to turn an IPv6 address into a 32-bit identifier
> - MD5 can be used for authentication without constraint
> - AES-CMAC cannot be used for authentication.
> I do not have a view on the first but see the second and third as 
> contradicting RFC8573 and so in need of change.  Allowing AES-CMAC I see 
> as not controversial but do not have a view as to what to do with MD5 
> used for authentication e.g.
> - allow without constraint
> - allow, but deprecated, in the YANG
> - allow with a note in Security COnsiderations
> - do not allow in the YANG
> etc.
> I am still sitting on the fence on that issue, lacking the secuirty 
> insight as to what would be acceptable, to you and the IESG.

I would mostly have expected the MD5 authentication option to be split off
into a separate YANG module that aguments the base one, or maybe hidden
behind a YANG feature, in order to give implementations the ability to "do
the right thing" (that is, expose only the modern crypto) while remaining
compliant with the primary YANG module.  As far as I know, either of those
options would still make it pretty trivial to also expose the MD5
functionality for legacy compatibility (which is in some different sense
also "the right thing to do", at least for now), but would make it clear
that it's not endorsed by the IETF to the same level.

-Ben