Re: [rtcweb] JSEP fingerprint hash requirements

On 10/18/2013 06:34 PM, Martin Thomson wrote:
> On 17 October 2013 18:38, Eric Rescorla <ekr@rtfm.com> wrote:
>> I'm not sure this was a sensible rule on 4572, but I don't think it's
>> particularly harmful.
> Right.  I'd have gone with a rule that said: MUST validate a
> "strong-enough" hash; MAY ignore others; MUST fail validation if any
> hash doesn't match.  That gives you backwards compatibility + hash
> agility.
>
> That only works of course if there is only one potential certificate
> that can be used.  If you have to allow for several, then that doesn't
> work.  But then you lose the advantages of the above.

The interesting cases are:
Consider 2 hash algorithms, A and B.
Receiving browser supports A, but not B.

Fingerprint uses A, certificate uses A: No problem.
Fingerprint uses B, certificate uses B: Browser can't verify 
fingerprint, but can't use cert anyway.
Fingerprint uses A, certificate uses B: Browser can verify that it got 
the right useless certificate.
Fingerprint uses B, certificate uses A: Browser can't verify the 
certificate, so can't trust it, even though it might have been useful.

Note that whether  A or B is the stronger hash is not relevant to this 
exercise.

When receiving browser supports both A and B, we could argue that they 
should be allowed to be different in the name of algorithm agility. But 
is there a real gain in security achieved by it?

>
>>> That should probably be written down, of course.
>> Agreed.
> The question is: where?
>
> I have a few hours, maybe I can write down an update to 4572 that fixes this.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb