Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - Martin's technical comment

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 May 2016 15:23:15 +0000

Hi,

>Aside from a bunch of grammatical errors (below), my concern is that this design ends up relying on >the weakest mutually supported hash function.  If SHA-1 is bad (hint: it is), but we have to support it, I >would prefer an algorithm that matched ALL mutually supported hashes.
>That is, if a peer supports SHA-256 it either includes SHA-256 for every certificate or checks that there >is a match for SHA-256 if any SHA-256 hash is present.

So, we can't assume that, if there is a SHA-1 hash and a SHA-256 hash, the receiver wouldn't use to SHA-256 has to check for a match (assuming the receiver supports SHA-256, that is)?

Isn't this a case where we have to trust that implementers to "the right thing"? An implementer could choose to not check anything - no matter what we specify...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 May 2016 15:25:23 +0000

Spelling error. The first sentence should say:

So, we can't assume that, if there is a SHA-1 hash and a SHA-256 hash, the receiver wouldn't use the SHA-256 to check for a match (assuming the receiver supports SHA-256, that is)?

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 May 2016 18:23
To: Martin Thomson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - Martin's technical comment

Hi,

Regards,

Christer

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 May 2016 16:23:18 +0000

> On May 9, 2016, at 11:25 AM, Christer Holmberg <[email-masked]> wrote:
> 

The problem is that we can’t easily distinguish Roman’s use case (separated RTP/RTCP, where the RTP implementation supports SHA-256 but the RTCP implementation doesn’t) from a case where an attacker has somehow subverted SHA-1.  In both cases, the presented (RTCP) certificate matches for one of the SHA-1 fingerprints, but not for any of the SHA-256 fingerprints.

We could potentially declare Roman’s use case to be disallowed, of course.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 May 2016 17:57:35 +0000

Hi,

>The problem is that we can’t easily distinguish Roman’s use case (separated RTP/RTCP, where the RTP implementation supports SHA-256 but the RTCP implementation doesn’t) from a case where an >attacker has somehow subverted SHA-1.  In both cases, the presented (RTCP) certificate matches for one of the SHA-1 fingerprints, but not for any of the SHA-256 fingerprints.
>

Earlier it was suggested that you must provide the same set of hashes for every certificate. That means that, for each certificate, there must be one match for each hash algorithm.

Question: how many hashes can we expect people to provide for each certificate? More than two?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 15:13:39 -0400

On Mon, May 9, 2016 at 1:57 PM, Christer Holmberg <
[email-masked]> wrote:

> >> So, we can't assume that, if there is a SHA-1 hash and a SHA-256 hash,
> the receiver wouldn't use the SHA-256 to check for a match (assuming the
> receiver supports SHA-256, that is)?
> >
> >The problem is that we can’t easily distinguish Roman’s use case
> (separated RTP/RTCP, where the RTP implementation supports SHA-256 but the
> RTCP implementation doesn’t) from a case where an >attacker has somehow
> subverted SHA-1.  In both cases, the presented (RTCP) certificate matches
> for one of the SHA-1 fingerprints, but not for any of the SHA-256
> fingerprints.
> >

This is not just my use case. This also affects Cullen's use case where it
is not known in advance which server will generate the media, so you
provide fingerprints for multiple unrelated servers. Each of those servers
can implement different hashes. Removing these use cases will be
inconvenient (multiple servers will have to be updated at the same time),
but it is workable since all those servers are typically under a single
party control.

Earlier it was suggested that you must provide the same set of hashes for
> every certificate. That means that, for each certificate, there must be one
> match for each hash algorithm.
>

This all depends if all certificates must provide a fingerprint for each
hash algorithms. If this is a requirement, then providing multiple
fingerprints can be used to improve connection security. This means the
more different fingerprints are provided, the more secure is the
connection. Because of this, someone can provide several fingerprints per
certificate to improve security.

If different certificates can provide different hashes, then numbers of
fingerprints per certificate will depend on the number of "legacy" hash
algorithms end point need to support. If end point can communicate with
three different end point versions all supporting different hashes, then it
will need to include three fingerprints per certificate. If you are working
with hardware end points, you need to support a lot of legacy versions.
Normally with software clients such as webrtc, number of legacy versions is
limited, and I do not expect to have more then two hashes per certificate
at any given time.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 May 2016 17:42:38 -0400

On 5/9/16 3:13 PM, Roman Shpount wrote:
> On Mon, May 9, 2016 at 1:57 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> This is not just my use case. This also affects Cullen's use case where
> it is not known in advance which server will generate the media, so you
> provide fingerprints for multiple unrelated servers. Each of those
> servers can implement different hashes. Removing these use cases will be
> inconvenient (multiple servers will have to be updated at the same
> time), but it is workable since all those servers are typically under a
> single party control.
>
>     Earlier it was suggested that you must provide the same set of
>     hashes for every certificate. That means that, for each certificate,
>     there must be one match for each hash algorithm.
>
> connection. Because of this, someone can provide several fingerprints
> per certificate to improve security.
>
> three different end point versions all supporting different hashes, then
> it will need to include three fingerprints per certificate. If you are
> working with hardware end points, you need to support a lot of legacy
> versions. Normally with software clients such as webrtc, number of
> legacy versions is limited, and I do not expect to have more then two
> hashes per certificate at any given time.

Is providing fingerprints for multiple certificates a use case that is 
currently deployed? Or is it only a potential future use case?

If it is a current use case, how is it working given the lack of 
consensus on how fingerprints are to be interpreted?

If it is only a future use case, then I suggest we devise an extension 
to the fingerprint attribute that allows the association of fingerprints 
with particular certificates, or to be placed in groups that each apply 
to a particular certificate.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 17:51:12 -0400

> currently deployed? Or is it only a potential future use case?

This is currently supported. I will do a small survey of the open source
DTLS-SRTP implementations and will report what they do exactly. I am fairly
sure they accept the media if any fingerprint matches.

If it is a current use case, how is it working given the lack of consensus
> on how fingerprints are to be interpreted?
>
> If it is only a future use case, then I suggest we devise an extension to
> the fingerprint attribute that allows the association of fingerprints with
> particular certificates, or to be placed in groups that each apply to a
> particular certificate.
>

I am not sure there is a reason to complicate things even for the future
use case. At least no use case why more then one fingerprint match is
needed was ever provided.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 09:59:54 +1000

On 10 May 2016 at 05:13, Roman Shpount <[email-masked]> wrote:
> is not known in advance which server will generate the media, so you provide
> fingerprints for multiple unrelated servers. Each of those servers can
> implement different hashes. Removing these use cases will be inconvenient
> (multiple servers will have to be updated at the same time), but it is
> workable since all those servers are typically under a single party control.

But this is easy, isn't it?  You know the certificate for each of
those servers and you either support SHA-foo or not.  That those
servers can only validate MD5 (and will be vulnerable) doesn't matter
as much as the fact that you aren't making any material impact on
security.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 20:50:44 -0400

On Mon, May 9, 2016 at 7:59 PM, Martin Thomson <[email-masked]>
wrote:

> it
> provide

Signaling agent that generates an offer on behalf of several media servers
might not know the actual certificates for each of the servers and only
have access to fingerprints. This of cause can be fixed to force the media
servers to provide the complete certificates, since communication protocol
between media server and signaling agent is something that should be under
control of the same developer. Fixing this might be inconvenient, but
definitely doable.

More important question is, if end point considers SHA-1 secure enough and
will accept offers with SHA-1, why forcing it to check SHA-1 and SHA-256
if SHA-256 is present would make connections more secure? If something
wants to attack such connection and SHA-1 is compromised, attacker can
simply cause the bid down to SHA-1 by removing SHA-256 fingerprint from the
offer.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 11:07:34 +1000

On 10 May 2016 at 10:50, Roman Shpount <[email-masked]> wrote:
> will accept offers with SHA-1, why forcing it to check SHA-1 and SHA-256 if
> SHA-256 is present would make connections more secure?

That is fine.  That endpoint is vulnerable, but what you are
advocating makes its peer vulnerable too.

In general, the idea when designing security mechanisms is to ensure
that the *strongest* common primitive has to be broken to mount an
attack.  That's really hard, and we've failed at it in the past for
other protocols, but when the solution is so simple in this case, it
seems like a no-brainer to me.

> If something wants to attack such connection and SHA-1 is compromised, attacker can simply cause the bid down to SHA-1 by removing SHA-256 fingerprint from the offer.

The requirement (as is always the case with DTLS-SRTP) is that
signaling has integrity.  After all, if they can change signaling,
they can just insert their own certificate hash.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 22:24:01 -0400

On Mon, May 9, 2016 at 9:07 PM, Martin Thomson <[email-masked]>
wrote:

> if
I think you are missing my point. If end point considers a single
fingerprint with SHA-1 has secure enough for some connections, why would it
not be secure enough for others even if other, more secure hashes, are
present there? A hash algorithm is either secure enough or not secure
enough. If hash is secure enough, why something else must be checked? If it
is not secure enough, why does it have to be checked at all?

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 12:44:00 +1000

> is not secure enough, why does it have to be checked at all?

Let's be clear, if someone thinks that SHA-1 is all they need to
implement (which is insane based on recent progress in cryptanalysis),
then we aren't making them implement others.

The reason that you want to implement two hash algorithms is so that
you can talk to multiple people: the ones with the good one (SHA-256)
and the one that you tolerate because you have to talk to people with
old software that can't be easily updated (SHA-1).  However, once you
support both, you create the potential for a bid-down from the good
one to the bad one unless you do as I have suggested.

Of course, what would be ideal is that every DTLS-SRTP implementation
would use SHA-256.  Right away.  That seems unlikely.