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

[Roman Shpount <[e-mail]>]

On Thu, Feb 2, 2017 at 12:15 PM, Paul Kyzivat <[e-mail]>
wrote:

> 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."
>

What we are trying to say is:

There MUST be a fingerprint matching the used certificate for each hash
algorithm present. End point SHOULD pick a set of one or more preferred
hash functions that should be checked to satisfy end point's security
requirements. Unless there is a matching fingerprint for each tested hash
function, the endpoint MUST NOT establish the TLS connection. It is
recommended that a single matching SHA-256 fingerprint should be sufficient
to verify the certificate.

Think of this as personal ID. You need one photo ID to get on the plain,
but bank will ask for two forms of ID before giving you money.
_____________
Roman Shpount