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

[Paul Kyzivat <[e-mail]>]

On 2/2/17 3:28 AM, Christer Holmberg wrote:
> Hi Paul,
>
>>>> ----------------------------------------------------------------------
>>>> 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.
>
> The question was WHY an endpoint would check more than one hash function
> to begin with, and the only reason we have came up with is if the endpoint
> doesn¹t ³know" which is the strongest hash - which sounds a little weird.

I don't see why we need to know why. Maybe they intend to try them all, 
just for completeness.

But if there is ever a question about the validity of an implementation, 
I don't want to be arguing with somebody who says:

"I tried them all, and several failed but one succeeded so I decided it 
must be ok."

	Thanks,
	Paul