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

[David Mandelberg <[e-mail]>]

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/