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

[Roman Shpount <[e-mail]>]

On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat <[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.

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