Re: [MMUSIC] 4572 update: forbid weak hashes?

[Paul Kyzivat <[e-mail]>]

On 4/7/16 3:08 PM, Roman Shpount wrote:
> On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     If you check the strongest hash you can and it succeeds, then what
>     is the point of checking any others?
>
>
> If you check any hash that you consider secure and it succeeds, you do
> not need to check any others. There is no difference if it is the
> strongest or just the hash that is strong enough.

>     The one check should be sufficient if there is only one stream. It
>     is a bit more complex if there are multiple streams (e.g., RTP and
>     RTCP).
>
>     How about:
>
>     1) implement as many as you can of hashes you consider strong enough.
>
>     2) for all the streams you are originating:
>         include fingerprints using all the hashes you support.
>         (Or is it ok to include fewer?)
>
> It might be ok to include fewer but I cannot think of a single reason
> why you would do this.
>
>     3) for streams you are receiving:
>
>     3.1) discard any fingerprints using hashes you don't support,
>           and any that you consider too weak to be trusted.
>
>     3.2) sort the remaining fingerprints, strongest hashes first.
>
> There is no reason to sort. This will not make hash check any more
> secure. If a hash you consider secure is compromised you will just get
> false positive slightly later. There is probably a reason to sort hashes
> based on the amount of resources it will take for you to check them,
> with easiest to check first  in order to optimize the hash checking
> process. This will likely sort the hashes weakest first.

If everybody did this, and the easiest to check one is compromised, and 
used by a MiTH to inject a bogus cert that matches that nobody might 
notice. Isn't that undesirable?

	Thanks,
	Paul

>     3.3) for each stream, check fingerprints from the list in order
>           until you find one that matches.
>           Reject the session if none match.
>
>
> Once again, if any match accept the session. If none match, reject.
> Checking order does not matter and will not affect overall security.
>
> Regards,
> _____________
> Roman Shpount