Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On Aug 8, 2017, at 6:48 AM, Dhruv Dhody <[e-mail]> wrote:
> 
> Hi Ben, 
> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: 08 August 2017 03:08
>> To: Dhruv Dhody <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> The IESG <[e-mail]>; [e-mail]
>> 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