Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

["Ben Campbell" <[e-mail]>]

On 1 Feb 2017, at 14:04, Christer Holmberg wrote:

> Hi Alissa,
>
> Thank you for your review! See below.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>> Section 5.1 says:
>>
>>  "An endpoint MAY, in addition to its more preferred hash function,
>>   also verify that each certificate used matches fingerprints
>>   calculated using other hash functions.  Unless there is a matching
>>   fingerprint for each tested hash function, the endpoint MUST NOT
>>   establish the TLS connection."
>>
>> This seems a little weird to me. It's up to the endpoint to decide 
>> whether to check for errors, and then if it
>> does find an error it can't setup the connection, whereas if it just 
>> hadn't checked it would be able to setup
>> the connection. I think it would help to explain why an endpoint 
>> would be motivated to check multiple fingerprints.
>
> I think the only use-case that came up was a situation where the 
> receiver is not sure which hash function is the "strongest", and 
> therefor checks multiple. However, it was also realized that with the 
> multiple set of hash functions such situation is very unlikely to 
> occur.
>
> So, I could add the following note:
>
> "NOTE: An endpoint might choose to match each used certificate against 
> fingerprints calculated using multiple
> hash functions e.g, if the endpoint is unsure which hash function is 
> the strongest."

In retrospect, I have to question that motivation. Is it that hard to 
figure out? It seems like if you have two hash functions that are 
reasonably equal, an implementation could just pick one.

>
> ...or we could simply delete the text. I personally would go for that, 
> but in case others want to keep it I have no problem with that.

Given that this has caused confusion at every step, I support removing 
the text.

Thanks!

Ben.