Early Review of draft-ietf-pce-pceps-06

Request Review of draft-ietf-pce-pceps
Requested rev. no specific revision (document currently at 18)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2015-12-03
Requested 2015-11-26
Authors Diego Lopez, Oscar de Dios, Qin Wu, Dhruv Dhody
Draft last updated 2015-12-03
Completed reviews Secdir Early review of -06 by David Mandelberg (diff)
Rtgdir Last Call review of -12 by Dan Frost (diff)
Secdir Last Call review of -14 by David Mandelberg (diff)
Genart Last Call review of -14 by Dale Worley (diff)
Opsdir Last Call review of -14 by Tianran Zhou (diff)
Assignment Reviewer David Mandelberg
State Completed
Review review-ietf-pce-pceps-06-secdir-early-mandelberg-2015-12-03
Reviewed rev. 06 (document currently at 18)
Review result Has Issues
Review completed: 2015-12-03



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.

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 



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