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

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Aug 2017 10:30:30 +0100

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.

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.

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.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Aug 2017 10:32:12 +0300

> issue that applies to a major MPLS protocol widely used throughout the 

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

> 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... 

-- 
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 Aug 2017 12:50:51 +0100

How about if we changed the security text to something of the form:

In general the security measures described in [RFC4447bis 
<https://tools.ietf.org/html/draft-ietf-pals-p2mp-pw-03#ref-RFC4447bis>] are adequate for this
protocol. However the use of MD5 as the method of securing an LDP
control plane is no longer considered adequately secure. Implementations should be
written in such a way that they can migrate to a more secure cryptographic
hash function when that function is agreed as the new default hash for LDP.

- Stewart
(speaking as Shepherd)

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 1 Sep 2017 01:50:47 +0300

Stewart Bryant writes:
> In general the security measures described in [RFC4447bis] are
> adequate for this protocol. However the use of MD5 as the method of
> securing an LDP control plane is no longer considered adequately
> secure. Implementations should be written in such a way that they
> can migrate to a more secure cryptographic hash function when that
> function is agreed as the new default hash for LDP.

Looks mostly good, except I would say "... can migrate to more secure
authentication algorithm when ...", i.e., the next authentication
method to be used in the LDP might not be simple hash based
authentication algorithm. 
-- 
[email-masked]