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

[Paul Kyzivat <[e-mail]>]

On 2/1/17 3:24 PM, Ben Campbell wrote:
> 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.

ISTM that the main point here is: *if* the recipient happens to check 
more than one hash, a failure of any one of them is to be considered an 
overall failure, rather than a success of one and a failure of another 
being considered a success.

Perhaps that ought to be obvious, but I have long since given up giving 
the benefit of the doubt on obviousness.

	Thanks,
	Paul