> On Aug 8, 2017, at 6:48 AM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:
> 
> 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)
>> 
> (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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to