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 " mean that must be implemented as an option, or that 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/