Re: [secdir] secdir review of draft-ietf-pce-pceps-06

Julien Meuric <> Tue, 01 December 2015 17:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 968901ACE6B; Tue, 1 Dec 2015 09:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.894
X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmJv17RQjai4; Tue, 1 Dec 2015 09:03:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D4421ACE69; Tue, 1 Dec 2015 09:03:00 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 9E3DDE30083; Tue, 1 Dec 2015 18:02:58 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 9023DE30082; Tue, 1 Dec 2015 18:02:58 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 1 Dec 2015 18:02:58 +0100
To: David Mandelberg <>
References: <>
From: Julien Meuric <>
Organization: Orange
Message-ID: <>
Date: Tue, 1 Dec 2015 18:02:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Approved-At: Tue, 01 Dec 2015 09:04:50 -0800
Subject: Re: [secdir] secdir review of draft-ietf-pce-pceps-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Dec 2015 17:03:02 -0000

Hi David,

Thanks a lot for this thoughtful review. I hope the authors will be able 
to respond soon.

Please note that the I-D has not been sent to the IESG yet, but is 
expected to after resolving your comments.



Dec. 01, 2015 -
> Hi,
> 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.
> I have a few concerns about this draft, detailed below. Otherwise it
> looks good though. As such, I think this draft is Almost Ready.
> Major:
> In section 3.4, the text about cipher suites requires support for
> negotiation of some cipher suites that I think are considered
> comparatively weak (primarily TLS_RSA_WITH_3DES_EDE_CBC_SHA). Is there a
> reason for the choice of suites that (I believe) are considered
> relatively weak? Also, does "implementations MUST support negotiation of
> <X>" mean that <X> must be implemented as an option, or that <X> must be
> implemented and enabled for use? If the latter, this might prevent
> people from disabling old cipher suites as new vulnerabilities are
> discovered. As I understand it, PCEP messages are sent unicast, so I
> don't see the value in enabling less secure cipher suites in situations
> where both endpoints are known to support more secure suites.
> Section 3.4 says "Certificate validation MUST include the verification
> rules as per [RFC5280]." Assuming that is referring to Section 6 of
> 5280, do you have any guidance on Section 6.1.3, step a.3 (revocation
> testing)? I.e., are PCEPS implementations expected to download CRLs, use
> OCSP stapling, or something else?
> Section 4.1 talks about the use of DANE/TLSA to authenticate a TLS
> server. While TLSA is sufficient for authentication, it is not
> sufficient for authorization, because anybody with a DNSSEC-enabled
> domain can create a valid TLSA record. And that's fine, as long as
> authorization is properly set up as described in section 3.5. However,
> the other two authentication models (PKI, and a list of acceptable
> certificate fingerprints) can be sufficient for authorization if only
> authorized parties are issued certificates or have their fingerprints
> listed (respectively). To avoid confusion, it would be nice if section
> 4.1 explicitly said that the server's domain name must be authorized
> separately, as TLSA does not provide any useful authorization guarantees.
> Minor:
> In section 3.3, I'm confused about the StartTLSWait timer. Is the timer
> started after the TCP connection is established (what the draft says) or
> after a StartTLS message is sent? If the latter, is the timer started
> even if a StartTLS message has already been received?