Subject: [rtcweb] JSEP fingerprint hash requirements

From: Kevin Dempsey <[email-masked]>
Date: Thu, 17 Oct 2013 09:37:10 +0100

The JSEP draft says that the fingerprint is REQUIRED to use sha-256 and
additional fingerprints using 'stronger' hashes can be included. However,
RFC 4572 says that the fingerprint hash must match the certificate's
signature algorithm. Recent chrome canary builds have stopped using sha-256
and use sha-1 as that matches their certificate's signature algorithm.

So:
1) does the fingerprinh hash need to match the certificate
2) do webrtc compatible endpoints need to handle hashes 'weaker' than
sha-256
3) are there any rules for handling multiple fingerprints?

Regards,
Kevin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Oct 2013 11:54:23 -0700

> 1) does the fingerprinh hash need to match the certificate

Yes.  Without that, you've got no binding between signaling and media
path, which is bad.

> 2) do webrtc compatible endpoints need to handle hashes 'weaker' than

No.  RFC 4572 is clear:
   A certificate fingerprint MUST be computed using the same one-way
   hash function as is used in the certificate's signature algorithm.

That means that you need to generate the certificate with a hash that
is strong enough.

> 3) are there any rules for handling multiple fingerprints?

RFC 4572 is silent on that, unless I missed something, which I
probably did.  The only plausible choice given the above statement
from 4572 is to suggest that multiple a=fingerprint values indicate
alternative certificates.

That should probably be written down, of course.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Oct 2013 18:38:52 -0700

> That means that you need to generate the certificate with a hash that

I'm not sure this was a sensible rule on 4572, but I don't think it's
particularly harmful. Here's my analysis: there are two kinds of
certs in play here:

- self-signed certs (most likely)
- CA-signed certs (less likely)

In the case of self-signed certs, you can control your digest. In the case
of
CA signed certs, someone is presumably going to verify the signature
and so we would expect the digest used to form that signature to be
reasonably strong.

> That should probably be written down, of course.

Agreed.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Oct 2013 09:34:40 -0700

On 17 October 2013 18:38, Eric Rescorla <[email-masked]> wrote:
> 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.

>> That should probably be written down, of course.

The question is: where?

I have a few hours, maybe I can write down an update to 4572 that fixes this.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 19:34:37 +0000

> I have a few hours, maybe I can write down an update to 4572 that fixes this.

that would be excellent if you could do that

---

From: Justin Uberti <[email-masked]>
Date: Fri, 18 Oct 2013 19:22:49 -0700

FWIW others have complained about this exact thing in JSEP and it will be
fixed in the -05 version (to agree with 4572).

On Thu, Oct 17, 2013 at 11:54 AM, Martin Thomson
<[email-masked]>wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Oct 2013 16:21:30 +0200

> 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?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 09:38:11 -0700

On 21 October 2013 07:21, Harald Alvestrand <[email-masked]> wrote:
> should be allowed to be different in the name of algorithm agility. But is
> there a real gain in security achieved by it?

Those are interesting cases, but they easily solved by saying
something like "MUST include/implement SHA-256".

I don't think that the hash used by the certificate is actually
relevant either.  Fingerprints are calculated, not observed or
extracted.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Oct 2013 19:53:14 +0200

> relevant either.  Fingerprints are calculated, not observed or
Welll... if the hash is what I think it is, you need to compute the hash 
of the certificate (in the algorithm specified in the certificate) in 
order to verify the RSA signature of the certificate.

So if you don't understand the hash algorithm the certificate specifies 
.... you can't verify the certificate's signature, and you are open to a 
forged-certificate attack. Again - saying that they have to be the same 
means that you only have to deal with one bad situation (you understand 
neither), and not three bad situations (you are toast because there's 
one of them you don't understand).

But I'm not a REAL crypto expert.  I may have misunderstood something.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 10:57:56 -0700

On 21 October 2013 10:53, Harald Alvestrand <[email-masked]> wrote:
> you can't verify the certificate's signature,

That's somewhat orthogonal.  And thankfully, not necessary unless you
intend to use the certificate for anything more than its public key.
And in at least some of the cases we are talking about, we only need
that to work.

But then you are talking about a different sort of problem, which is a
well-known one, which is the validation of certificates.  I'm talking
about a=fingerprint.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 16:40:31 -0700

> that would be excellent if you could do that

Done.

http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00

I wasn't able to pass this under any noses before pushing the button,
so this is probably way off base or duplicative of Justin's promised
efforts.  We can discuss in MMUSIC.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 21 Oct 2013 16:57:21 -0700

Lacking anything else to point at, I changed the text in jsep-05 to just
reiterate the policy from 4572.

However, it does raise the larger question of what digest (and perhaps key
length) should be used when generating certificates in WebRTC, and where
that should be specified.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 20:01:28 -0700

> reiterate the policy from 4572.

Probably sensible, even if 4572 falls short.

> that should be specified.

The main factors that affect WebRTC are the size of the RSA modulus
(if we're still doing that) and the digest function used for identity
validation.  The first is largely a unilateral decision, once we sort
out whether we want RSA or RSA + DH or one of the EC options.
Currently, there is no way to get hash agility with the mechanism
defined in security-arch, a problem I think we should discuss.

--Martin

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Oct 2013 14:24:14 +0200

> something like "MUST include/implement SHA-256".

Until SHA-512 comes along.

If I don't support SHA-512, and the certificate says you have to use 
SHA-512 to verify the certificate, but I have a fingerprint using 
SHA-256, am I exposed to some attack I'd have been protected against if 
I understood SHA-512, or not?
> relevant either.  Fingerprints are calculated, not observed or

Well - they are extracted from SDP, and compared, which is a form of 
observation.... but you may be thinking of something else; I find that 
sentence hard to parse.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Oct 2013 08:39:41 -0700

On Tue, Oct 22, 2013 at 5:24 AM, Harald Alvestrand <[email-masked]>wrote:

>>> is
> SHA-512 to verify the certificate, but I have a fingerprint using SHA-256,
> am I exposed to some attack I'd have been protected against if I understood
> SHA-512, or not?

I'm not quite sure I follow. If the certificate isn't being third-party
validated,
it's irrelevant what digest was used to sign the certificate.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2013 09:14:09 -0700

> it's irrelevant what digest was used to sign the certificate.

What EKR said.  It's all in the draft.  For 4572, aside from secondary
uses, the certificate is primarily used as a container for a public
key.  The hash forms a binding between the public key (by hashing its
container) and the actual session description.  Then, all you need is
some form of trust in the integrity of the session description.

Of course, once we go to webrtc, the integrity of the session
description is immediately suspect.  RFC 4572 provides close to zero
utility for webrtc.  Identity providers use a separate binding of the
same form to bind an identity assertion to the public key that is
independent of the integrity of the signaling channel.