Hi Ben, 

> -----Original Message-----
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: 08 August 2017 03:08
> To: Dhruv Dhody <dhruv.dh...@huawei.com>
> Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> The IESG <i...@ietf.org>; pce-cha...@ietf.org
> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)
> >>
> >>>
> >>>> - 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 

> >
> > (snip)
> >

Pce mailing list

Reply via email to