Hi Ben, Please see inline...
> -----Original Message----- > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: 03 August 2017 20:57 > To: Dhruv Dhody <dhruv.dh...@huawei.com> > Cc: The IESG <i...@ietf.org>; cmarga...@juniper.net; draft-ietf-pce- > pc...@ietf.org; pce@ietf.org; pce-cha...@ietf.org > Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: > (with DISCUSS and COMMENT) (snip) > >> > >> --------------------------------------------------------------------- > >> - > >> 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? > [[Dhruv Dhody]] There was substantive discussion on the mailing list regarding this, as our original proposal requested a new port and we were advised to use StartTLS instead after discussion with transport/security folks. See https://www.ietf.org/mail-archive/web/pce/current/msg03540.html. > > > > >> - 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? > [[Dhruv Dhody]] SHA-256 is the current mandatory hash, others might become usable and useful as the technology evolves. Do you have any suggested change in mind? I see RFC6614 use similar language "Implementations MUST support SHA-1 as the hash algorithm for the fingerprint...." (snip) > >> - 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? > [[Dhruv Dhody]] On further discussion with my co-authors, we feel we should remove the statement. The previous statement in the draft about mutual authentication is enough and mutual authentication should be the standard. Regards, Dhruv > […] > Thanks! > > Ben. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
