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

DIEGO LOPEZ GARCIA <> Tue, 08 December 2015 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6AD51B2F06; Tue, 8 Dec 2015 07:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rtqSVPyhNUBm; Tue, 8 Dec 2015 07:59:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EC6A1B2F5B; Tue, 8 Dec 2015 07:59:51 -0800 (PST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 6BA68370160; Tue, 8 Dec 2015 16:59:49 +0100 (CET)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E8F33700EF; Tue, 8 Dec 2015 16:59:49 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 8 Dec 2015 16:59:48 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.337.19; Tue, 8 Dec 2015 15:59:47 +0000
Received: from ([]) by ([]) with mapi id 15.01.0337.015; Tue, 8 Dec 2015 15:59:47 +0000
To: David Mandelberg <>
Thread-Topic: secdir review of draft-ietf-pce-pceps-06
Thread-Index: AQHRLACA/j1u7nVwA062pV1TsIHyqZ7BSZaA
Date: Tue, 8 Dec 2015 15:59:47 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; DB4PR06MB0624; 5:W7o1qWCLIwFZItMgnNJYHDl4TCTADIcl3mSqwOC7HOmTrm4nEiwfGXcgXMZdFYdDrNsvRH24kQtmVLROShHCftRkxqnfYc+Gn8YjKRqYjow05qDZ2YwABaiIcJuEpvb1zvdKJJbERfIIc2Q5GhUmyA==; 24:8F9BJULGxlYFtLI47vplbmpyupzcjFlaKXh9nwRWgEUTEDbezfirk1bBpBu0kc+OXtpjSdDeBB/TPE+7jqS4kf4vKh3u0+I2W3ajzErC+dc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(40392960112811);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624;
x-forefront-prvs: 0784C803FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(24454002)(252514010)(199003)(189002)(19617315012)(87936001)(92566002)(1220700001)(1096002)(77096005)(40100003)(105586002)(6116002)(122556002)(83716003)(19580395003)(11100500001)(19580405001)(50986999)(33656002)(15975445007)(2900100001)(36756003)(2950100001)(101416001)(3846002)(230783001)(106356001)(97736004)(76176999)(66066001)(86362001)(10400500002)(81156007)(586003)(102836003)(110136002)(54356999)(106116001)(5002640100001)(5004730100002)(5008740100001)(16236675004)(82746002)(5001960100002)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_030AC7B75C3B401794D840351061ED47telefonicacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 15:59:47.0085 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624
Archived-At: <>
X-Mailman-Approved-At: Tue, 08 Dec 2015 08:03:49 -0800
Cc: "" <>, The IESG <>, "" <>
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, 08 Dec 2015 15:59:57 -0000


Thanks for the review and comments. I plan to address the actions I include inlined below during the coming days, once the current pressing issues around the end of the year (what made me delay in my reply as well) are over. I’ll upload a new version according to them and the comments we have recently received, mostly from Tom Petch.

On 1 Dec 2015, at 07:21 , David Mandelberg <<>> 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.

I have a few concerns about this draft, detailed below. Otherwise it looks good though. As such, I think this draft is Almost Ready.


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.

DRL> The listed ciphersuites are inspired (as said in the acknowledgements) in what is listed in RFC, as the authors perceived a clear parallelism between the cases of PCE and RADIUS. I know the discussion on the required ciphersuites was long and a compromise between strength and common availability (by the moment of that discussion) was made. I acknowledge things have changed since then and I am happy to change the list, or even to make a direct reference to an up-to-date list that is likely to well reasonably well maintained.

DRL> The negotiation issue you mention is there for a similar reason, and it can be eliminated as well, especially if we could have the reference to an up-to-date list.

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?

DRL> I think we can RECOMMEND that PCEPS implementation incorporate revocation methods (CRL downloading, OCSP…) according to the trusted CA policies

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.

DRL> Will do!


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?

DRL> The StartTLSWait timer is started after the StartTLS message is sent, you are right there is an error in the draft, and once the StartTLS exchange is made the procedures to belong are those relating to TLS handshake. This implies that a StartTLS sent in reply to the peer’s StartTLS does not start the timer. It will be corrected.

Be goode,

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

Tel:    +34 913 129 041
Mobile: +34 682 051 091


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição