Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03

Tero Kivinen <kivinen@iki.fi> Mon, 28 August 2017 07:32 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF8913271E; Mon, 28 Aug 2017 00:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 kygT1ahWuv1Q; Mon, 28 Aug 2017 00:32:19 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 5D0A81326BB; Mon, 28 Aug 2017 00:32:19 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7S7WDK4027159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Aug 2017 10:32:13 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7S7WCN5013086; Mon, 28 Aug 2017 10:32:12 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22947.50940.679445.270481@fireball.acr.fi>
Date: Mon, 28 Aug 2017 10:32:12 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org, "mpls-chairs\@ietf.org" <mpls-chairs@ietf.org>
In-Reply-To: <aed969e4-31be-cf77-8bbe-598f0407c4f3@gmail.com>
References: <201708270627.v7R6RLjk004141@fireball.acr.fi> <aed969e4-31be-cf77-8bbe-598f0407c4f3@gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 2 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Gu-2iXQ88VhUXkGgBGT9856wUzs>
Subject: Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Aug 2017 07:32:22 -0000

Stewart Bryant writes:
> Tero
> 
> Thank you for your comment.
> 
> I believe that it if wrong to hold this document hostage to a security 
> issue that applies to a major MPLS protocol widely used throughout the 
> Internet.

I agree on that, but I think the text claiming "security is adequate"
in the security considerations section is also wrong, so it should be
fixed to include note explaining what you explained below:

> The right way to address the problem is via an update to the security of 
> LDP (in the MPLS WG) and have that specification update the RFCs that 
> use LDP.
> 
> If an attacker were able to use the vulnerability in MD5 as a vector to 
> attack LDP, I doubt that this relatively low key aspect of pseudowires 
> would be their first priority.

I.e., current security is using MD5, which is not considered safe, but
this document will be able to use the better security mechanisms when
they are defined, and there are better targets to attack if attacker
is able to break MD5 based security... 

> Regards
> 
> - Stewart
> 
> 
> On 27/08/2017 07:27, Tero Kivinen wrote:
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > This document describes the mechanims to signal point-to-multipoint
> > pseudowires using LDP. The security considerations section simply
> > points to the RFC4447bis (i.e., RFC8077) saying that security
> > mechanisms described there are adequate.
> >
> > On the other hand RFC8077, says that LDP MD5 authentication key option
> > as described in the section 2.9 of RFC5036 MUST be implemented. The
> > section 2.9 of RFC5036 describes TCP MD5 signature option for LDP.
> > This might have been adequate security for some protocol in 2007 (when
> > RFC5036 was published, altought MD5 was already then known to be
> > broken), but it IS NOT adequate security in 2017.
> >
> > I understand that this document is not really the one supposed to
> > update the security option for the LDP, but there is
> > draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard
> > still trying to keep the same broken MD5 based security in it. I think
> > this document should include note saying, that security of the RFC5036
> > is no longer adequate for any use because it uses broken security
> > protocol, but there is nothing better out there yet (or is there, I do
> > not know enough of the LDP to know that), and perhaps point to the
> > rfc5036bis also in hopes that it might some day fix the security of
> > the LDP.
> >
> > I think this document (or whole PW and LDP system) has issues that
> > needs to be fixed before it can be published.

-- 
kivinen@iki.fi