Hi, also inline: Thanks!
Ben. > On Aug 4, 2017, at 1:40 PM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote: > > 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. Okay, good enough. > > >> >>> >>>> - 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…." I guess my question is whether the intent is for implementations to be able to pick any hash they want, as long as SHA-256 is an option, or do you expect everyone to use SHA-256 unless that is replaced at some point due to security concerns. If the former, “MUST support…” makes sense. If the latter, something like “MUST (or SHOULD) use…” with a caveat that future specs might update this if SHA-256 is proven unsafe at some point in the future. My real concern here is interoperability—if an implementation chooses a hash other than SHA-256, how does the peer know what hash to use? > > (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. Okay. > > Regards, > Dhruv > >> […] >> Thanks! >> >> Ben. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
