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

David Mandelberg <david@mandelberg.org> Tue, 01 December 2015 06:21 UTC

Return-Path: <david@mandelberg.org>
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 12BC91A7026 for <secdir@ietfa.amsl.com>; Mon, 30 Nov 2015 22:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 RVbolNJnb0kL for <secdir@ietfa.amsl.com>; Mon, 30 Nov 2015 22:21:03 -0800 (PST)
Received: from nm4-vm1.access.bullet.mail.bf1.yahoo.com (nm4-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.112]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A3C1A7020 for <secdir@ietf.org>; Mon, 30 Nov 2015 22:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448950862; bh=qDK8kMcsn0WtQLCmU4e44OuUQL1Jodl7lDILmu0jCtE=; h=Date:From:To:Subject:From:Subject; b=Q7WLjA7TjPUl161EU7dSLqgiakCKGmatTPNliZLMzbS0NK6cHfS2kr3MynX3JWvDy1nHjTn10uuFqiLpjm5kQ7iRzU7/pKsconh4LA2Y5nxpU2ZN/Y0x8Y2+MdohlGUzPDXCyanch+6/3q1n4hbqWOHVAHbhlJi62DojwlDX3Cg+JOnwLE2yrFmA3lIQ3xJNUI16wUvWuVtPtWNPxAaa7Y9ocP5pdppVJprSxxWETA2NpHzF8S61h6OzPutiZsfkx4mqcRjbemKOOo4KTnxCjuVTse3nfOQY2vjnUr5z+rz6VHIhfDpLRlkMPVs1v6cS/5U0rbhdkiyxVdln6myWiA==
Received: from [66.196.81.165] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2015 06:21:02 -0000
Received: from [98.138.104.96] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2015 06:21:02 -0000
Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 01 Dec 2015 06:21:02 -0000
X-Yahoo-Newman-Id: 30574.49991.bm@smtp116.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: .DbgZRwVM1lyioPw6GGNr0ZxNRRzYq5WS.mGH1GDmh2ETuu k6_ZFmYlRVZ6x2q97kjaHSeqdgyG7Tha.atKcbibDtVv81rXY3zQ1TRZ18LY xu3oktv56WA9VvZG0PVj3KTcppRNUUgSX2Ix6ljJwlvsm26XbGmDpAmrDgE0 8eS01eQt2o6r1qNqBZjaCiMlSzdptzfGU9tSWQKP5wM9kr1A2qiueq.5edwA aiuiC1QrmEX9gFVmugpQjuozg81k2LKyI2r7wg.wpsIgerL1.nCrZBbaSUUO ztawRaP26.x_j7ZmBKIMhhjIPwjDJoPGS4yIl6Fa90XKI2h_AU4giCIwMdGu akFvrky8_o8xC70euvsxU2jqj8rglhyQBOJHMOCxPrY6CTCz.mVh27tvI1hu CyKoPYOlTD4T7rurtN.7S1EOxjpDvomx.Cc7Q8gSFjWSSv85abr.rM3wKEQ6 O0wdPLD3NPCnSjhcgWAJNfBSZZPqR_qyRTQhRSATukfFWb.vyV738B1zda7_ VdwEsqaDcm_93VpaskMk4toD_tbSfaufnkWiHEg--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id C4DC11C6031; Tue, 1 Dec 2015 01:21:00 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 01 Dec 2015 01:21:00 -0500
From: David Mandelberg <david@mandelberg.org>
To: <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-pce-pceps.all@tools.ietf.org>
Message-ID: <3c90e45423a16059ac64e37c85bc71fe@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/41b5cf6XGzq3kCAIxMISPaROV3E>
Subject: [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 06:21:05 -0000

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?


-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/