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

[Stewart Bryant <[e-mail]>]

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)


On 28/08/2017 08:57, Tero Kivinen wrote:
> 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.