PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)
draft-ietf-pce-pceps-18
Yes
(Deborah Brungard)
No Objection
(Alia Atlas)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Warren Kumari
No Objection
Comment
(2017-08-01 for -15)
Unknown
I think that the document should explain why this does STARTTLS and not e.g another port (which would be more downgrade resistant) Obviously this is in addition to the DISCUSS held by EKR.
Alexey Melnikov Former IESG member
(was Discuss)
Yes
Yes
(2017-08-07 for -15)
Unknown
Thank you for addressing my DISCUSS points and comments. I think the text about use of RFC 6125 should use RFC 6125 terminology like DNS-ID and CN-ID, because they have a bit more semantics associated with them other than just subjectAltName:DNS. I think you should also clarify whether you want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).
Ben Campbell Former IESG member
(was Discuss)
Yes
Yes
(2017-08-07 for -15)
Unknown
Thanks for resolving my DISCUSS point and other comments via email. I'm clearing now under the assumption the discussed updates will make it into a future revision.
Deborah Brungard Former IESG member
Yes
Yes
(for -14)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(2017-08-02 for -15)
Unknown
I support EKR's discuss points, especially the first. I'm a yes assuming that all the discuss points will be addressed, as I do think this work is important and am glad to see it. In addition to other comments, I don't think anyone else commented on the use of the word "privacy" instead of confidentiality in the security considerations section. That should be changed. Thank you.
Alia Atlas Former IESG member
No Objection
No Objection
(for -15)
Unknown
Eric Rescorla Former IESG member
(was Discuss)
No Objection
No Objection
(2017-08-01 for -17)
Unknown
This document needs a significant editorial pass. I found a number of writing errors, e.g., "Securing via TLS of an existing PCEP session is not permitted," S 1. defining their application in depth. Moreover, [RFC6952] remarks the importance of ensuring PCEP communication privacy, especially when The term here is "confidentiality" S 3.2. The whole description of how you can race StartTLS iff you know you are TLS only is really hard to understand until you get to the diagrams. I would write something like: The PCC initiates the use of TLS by sending a StartTLS message The PCE agrees to the use of TLS by responding with its own StartTLS message. If the PCE is configured to only do TLS, it may send the StartTLS message immediately upon TCP connection establishment; otherwise it MUST wait for the PCC's first message to see whether it is an Open or StartTLS message. S 3.4. + Implementations SHOULD indicate their trusted CAs. For TLS 1.2, this is done using [RFC5246], Section 7.4.4, "certificate_authorities" (server side) and [RFC6066], Section 6 "Trusted CA Indication" (client side). Do common stacks do this? I know NSS does not. To support TLS re-negotiation both peers MUST support the mechanism described in [RFC5746]. Any attempt to initiate a TLS handshake to establish new cryptographic parameters not aligned with [RFC5746] SHALL be considered a TLS negotiation failure. Is there a reason to allow renegotiation at all? S 3.5 [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be included in the OPEN Object. It contains a unique identifier for the node that does not change during the lifetime of the PCEP speaker. An implementation would thus expose the speaker entity identifier as part of the X509v3 certificate, so that an implementation could use this identifier for the peer identification trust model. This seems underspecified. Is there an OID assigned? S 4.1. DANE [RFC6698] defines a secure method to associate the certificate that is obtained from a TLS server with a domain name using DNS, i.e., using the TLSA DNS resource record (RR) to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". The DNS information needs to be protected by DNS Security (DNSSEC). A PCC willing to apply DANE to verify server identity MUST conform to the rules defined in section 4 of [RFC6698]. The server's domain name must be authorized separately, as TLSA does not provide any useful authorization guarantees. This is also underspecified. Which DANE types are you suggesting you use? S 7. Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification does not forbid the use of such ciphersuites, but administrators must weight carefully the risk of relevant internal data leakage that can occur in such a case, as explicitly stated by [RFC6952]. Why don't you forbid it?
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-07-31 for -14)
Unknown
One high level comment: As already mentioned by the gen-art review (Thanks Dale for the detailed review!), for me the text was for a long time while reading not clear on who starts the TLS negotiation. In think there is a statement missing that a speaker/PCE that supports PCEPS and receives a StartTLS message MUST reply with a StartTLS message and further the PCC MUST initiation the TLS after reception of a StartTLS message from the PCC. More minor/editorial comments: 1) There are two cases where the behavior of speakers that do not support PCEPS is specified, which is a bit non-sensical given that not support probably means it does not follow this spec: OLD "If the PCEP speaker that does not support PCEPS, receives a StartTLS message, it MUST behave according to the existing error mechanism described in section 6.2 of [RFC5440] (in case message is received prior to an Open message) or section 6.9 of [RFC5440] (for the case of reception of unknown message)." NEW "If the PCEP speaker that does not support PCEPS, receives a StartTLS message, it will behave according to the existing error mechanism described in section 6.2 of [RFC5440] (in case message is received prior to an Open message) or section 6.9 of [RFC5440] (for the case of reception of unknown message)." and OLD "A PCEP speaker that does not support PCEPS or has learned the peer willingness to reestablish session without TLS, can send the Open message directly, as per [RFC5440]." NEW "A PCEP speaker that does not support PCEPS sends the Open message directly, as per [RFC5440]. A PCEP speaker that supports PCEPS but has previously already learned the peer willingness to reestablish session without TLS, MAY send the Open message directly, as per [RFC5440]." 2) As already mentioned in the gen-art review, I also think there should be more text on what a host should do that uses StartTLS but gets an error back. This is defined previously in the document but given there is an own section here, I would just recommend to re-iterate there. In other words please add the proposed text! 3) Why is this a MUST? sec 8.1 "A PCE or PCC implementation MUST allow configuring the PCEP security via TLS capabilities as described in this document." Wouldn't a SHOULD be enough/better? Meaning that when PCEPS is implemented and turned on by default, I don't necessarily have to provide a knob to turn it off? 4) Also related to the previous point sec 8.2 "An implementation SHOULD allow the operator to configure the PCEPS capability and various TLS related parameters, ..." Probably this part of sentence should not be normative given this part is (differently) specified in the previous section.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -15)
Unknown
Suresh Krishnan Former IESG member
(was Discuss)
No Objection
No Objection
(2017-08-09 for -16)
Unknown
Thanks for taking care of my DISCUSS points.
Terry Manderson Former IESG member
No Objection
No Objection
(for -15)
Unknown