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

Julien Meuric <julien.meuric@orange.com> Tue, 01 December 2015 17:03 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968901ACE6B; Tue, 1 Dec 2015 09:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.894
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmJv17RQjai4; Tue, 1 Dec 2015 09:03:00 -0800 (PST)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4421ACE69; Tue, 1 Dec 2015 09:03:00 -0800 (PST)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E3DDE30083; Tue, 1 Dec 2015 18:02:58 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 9023DE30082; Tue, 1 Dec 2015 18:02:58 +0100 (CET)
Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Tue, 1 Dec 2015 18:02:58 +0100
To: David Mandelberg <david@mandelberg.org>
References: <3c90e45423a16059ac64e37c85bc71fe@mail.mandelberg.org>
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <565DD2C1.8040108@orange.com>
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: <3c90e45423a16059ac64e37c85bc71fe@mail.mandelberg.org>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ddsvzAVh2nDcmMA9ohat_2Buosg>
X-Mailman-Approved-At: Tue, 01 Dec 2015 09:04:50 -0800
Cc: draft-ietf-pce-pceps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-pce-pceps-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: 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.

Cheers,

Julien


Dec. 01, 2015 - david@mandelberg.org:
> 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?
>
>