Thanks, please also see inline. I will remove sections that do not seem to need further comment.
> On Aug 3, 2017, at 8:35 AM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote: > > Hi Ben, > > Thanks for your review. See inline.. > >> -----Original Message----- >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ben Campbell >> […] >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> -3.4, step 2: "Peer validation always SHOULD include a check on whether >> the locally configured expected DNS name or IP address of >> the peer that is contacted matches its presented >> certificate." >> >> Why is that not a MUST? As it is, this need to at least discuss the risks >> involved if you don't check the identity of the peer cert (here or in the >> security considerations.) >> > [[Dhruv Dhody]] Reworded to say - > > + Implementations MUST follow the rules and guidelines for > peer validation as defined in [RFC6125]. If an expected > DNS name or IP address for the peer is configured, then the > implementations MUST check them against the values in the > presented certificate. Thanks, that would resolve my DISCUSS position. >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive: >> >> - I share Warren's question about why you chose STARTTLS over a dedicated >> port, especially since the 2nd to last paragraph in 3.2 goes out of its >> way to mention that. What were the tradeoffs involved that made adding the >> additional protocol machinery more attractive than allocating a port >> number? >> > [[Dhruv Dhody]] I have added this text - > > This document uses the standard StartTLS procedure in PCEP, instead > of using a different port for the secured session. This is done to > avoid requesting allocation of another port number for the PCEPS. > The StartTLS procedure makes more efficient use of scarce port > numbers and allow simpler configuration of PCEP. That’s helpful, but it only shows the benefits side of the tradeoff. I assume people thought the additional protocol complexity was a reasonable cost to bear? > >> - 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as >> the hash algorithm for the fingerprint." >> Do you really intend "MUST support" (meaning you have to be able to handle >> sha-256, but could allow other hashes) vs "MUST use"? >> > [[Dhruv Dhody]] Yes, additional hash algorithm MAY also be supported/used. > Is there an expectation people will use multiple hash algorithms side-by-side? Or is this for purposes of hash agility? >> - 3.5: "Implementations >> that want to support a wide variety of trust models SHOULD expose as >> many details of the presented certificate to the administrator as >> possible >> so that the trust model can be implemented by the administrator." >> "as much as possible" is pretty vague for the a 2119 SHOULD. Since the >> following sentences also include a SHOULD along with considerably more >> detail, I suggest dropping the SHOULD in this sentence, and leaving the >> one in the following sentence. >> > [[Dhruv Dhody]] Ack. > >> - 3.6: Is the exponential backoff requirement part of the procedures in >> 5440? >> The wording suggests that it is not. If so, it needs elaboration here. >> > [[Dhruv Dhody]] It is part of RFC5440, text updated to - > > The initiator SHOULD follow the procedure listed in [RFC5440] to > retry session setup as per the exponential back-off session > establishment retry procedure. > >> Editorial: >> >> - 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST >> respond with..." >> > [[Dhruv Dhody]] Ack > >> - 3.4 : "Negotiation of mutual authentication is REQUIRED." >> Does that mean that the peers must elect to use mutual authentication, or >> that if they want to use it, they must agree to do so? (The pattern >> persists throughout the section, but the meaning seems more obvious for >> some of the >> others.) >> > [[Dhruv Dhody]] I am also not sure, this was added keeping RFC6614 as our > reference. > Since TLS supports multiple authentication mode, this might be a say mutual > as well as server-only authentication should be supported. But not sure about > the word negotiation here. I think we can remove this statement, will do so > once you confirm. he The important thing is that the intent of the WG is clear. Do you mean to say that the working group intended to allow both server-only and mutual authentication, or do you mean to say the working group did not think about it? […] Thanks! Ben. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
