> On Aug 8, 2017, at 6:48 AM, Dhruv Dhody <[email protected]> wrote: > > Hi Ben, > >> -----Original Message----- >> From: Ben Campbell [mailto:[email protected]] >> Sent: 08 August 2017 03:08 >> To: Dhruv Dhody <[email protected]> >> Cc: [email protected]; [email protected]; [email protected]; >> The IESG <[email protected]>; [email protected] >> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: >> (with DISCUSS and COMMENT) >> > (snip) >>>> >>>>> >>>>>> - 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. >> > [[Dhruv Dhody]] I was incorrect in my reply before, it is the latter, as we > also have this text in the security considerations that explains this - > > When using certificate fingerprints to identify PCEPS peers, any two > certificates that produce the same hash value will be considered the > same peer. Therefore, it is important to make sure that the hash > function used is cryptographically uncompromised, so that attackers > are very unlikely to be able to produce a hash collision with a > certificate of their choice. This document mandates support for > SHA-256 as defined by [SHS], but a later revision may demand support > for stronger functions if suitable attacks on it are known. > > So a future revision would update the Hash function to be used. I will update > the text as you suggest. > >> 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? >> > [[Dhruv Dhody]] This is a local property and does not need to be exchanged. > The peer provides the certificate, based on local hash function in use, the > hash of DER encoded certificate octets is created and compared to a local > fingerprint configured.
Ah, that makes sense, thanks! (And in any case, the question is moot based on the rest of your response.) I can’t remember if I mentioned it, but I have cleared my DISCUSS position and entered a YES. Thanks! Ben. > >>> >>> (snip) >>> > > Regards, > Dhruv _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
