Early Review of draft-ietf-pce-pceps-06
review-ietf-pce-pceps-06-secdir-early-mandelberg-2015-12-03-00

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

Review
review-ietf-pce-pceps-06-secdir-early-mandelberg-2015-12-03

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/