Subject: Re: [MMUSIC] Request for draft adoption: draft-holmberg-mmusic-4572-update

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 10:55:45 -0400

Let me try to explain the issue:

When DTLS association is established you get the remote public key. You
might also get the remote public key signature as a part for DTLS
establishment, but this is only useful if this signature is generated by
trusted well known third party (certificate authority) and signed by its
certificate. Since for DTLS mostly self signed certificates are used, this
signature is completely irrelevant.

Once this public key is received, the receiving end point can generate a
hash signature (fingerprint) of this key. Fingerprint has nothing to do
with certificate signature. Fingerprint is completely independently
generated by the receiving end point, and it is not signed by any
certificate. The procedure to generate such fingerprint is different from
certificate signatures and its value is completely unrelated.

When validating a received public key, end point validates it against the
list of fingerprints provided in the SDP. End point generates a fingerprint
based on the hash algorithm specified in SDP fingerprint attribute and
compares the generated value with the value in the SDP. If values are the
same, the end point assume that fingerprint matches and this public key can
be trusted. If none of the fingerprint match, then this connection is
established by the untrusted remote and must be torn down.

The reason to use multiple fingerprints with different hash algorithms for
the same certificate is hash function agility. Imaging it is discovered
that SHA-256 is insufficiently secure and SHA-512 should be used instead.
It is physically impossible to update all communicating end points in the
network at the same time without shutting down the whole network. In order
to perform a gradual, rolling upgrade, end points are updated to include
both SHA-512 and SHA-256 fingerprints in SDP descriptions. Older end-points
will still accept keys used for connections based on older SHA-256
fingerprints. Newer end points will accept keys used for connections based
on either SHA-256 or SHA-512 fingerprints. Once all end points in the
network are updated to support SHA-512 fingerprints, another rolling update
is started to remove support for SHA-256 fingerprints. After this update
completes only newer, SHA-512 based fingerprints will be used in the
network.

Regards,
_____________
Roman Shpount

On Mon, Mar 21, 2016 at 10:23 AM, Paul Kyzivat <[email-masked]>
wrote:

> On 3/21/16 6:37 AM, Martin Thomson wrote:
>
>> On 21 March 2016 at 20:55, Roman Shpount <[email-masked]> wrote:
>>
>>>
>>> We should remove this requirement completely.
>>>
>>
>> Yes.  For a=fingerprint, the hash used in the certificate is
>> completely irrelevant.  More so, it could be a bad choice.
>>
>>
> I am still struggling to precisely understand the threat you are trying to
> address with this change, and then how the change is expected to work.
>
> Clearly both ends must understand the hash used in the certificate. The
> original requirement that the fingerprint use the same hash was intended so
> that no *additional* hashes had to be *mutually* understood by both ends.
>
> IIUC you are concerned because someone might want to use a cert with a
> weak hash, but want to have a stronger hash for the fingerprint.
>
> But that introduces something else that both ends have to mutually agree
> to. If both ends can be assumed to support a stronger hash for the
> fingerprint, why not for the cert too?
>
> Allowing multiple fingerprints, using different hashes, for the same cert
> implies that there isn't an assumption of complete mutual agreement. But
> then presumably with multiple fingerprints, some will be stronger than
> others. Doesn't that introduce the possibility of a downgrade attack?
>
> BTW, I notice this discussion doesn't include the entire mailing list.
> Given how it is evolving, ISTM this would benefit from discussion by the wg.
>
>         Thanks,
>         Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 14:25:51 -0400

Roman,

OK, now we are on the mmusic list. See below.

On 3/21/16 10:55 AM, Roman Shpount wrote:
> certificate. Since for DTLS mostly self signed certificates are used,
> this signature is completely irrelevant.
>
> certificate. The procedure to generate such fingerprint is different
> from certificate signatures and its value is completely unrelated.
>
> When validating a received public key, end point validates it against
> the list of fingerprints provided in the SDP. End point generates a
> fingerprint based on the hash algorithm specified in SDP fingerprint
> attribute and compares the generated value with the value in the SDP. If
> values are the same, the end point assume that fingerprint matches and
> this public key can be trusted. If none of the fingerprint match, then
> this connection is established by the untrusted remote and must be torn
> down.
>
> The reason to use multiple fingerprints with different hash algorithms
> for the same certificate is hash function agility. Imaging it is
> discovered that SHA-256 is insufficiently secure and SHA-512 should be
> used instead. It is physically impossible to update all communicating
> end points in the network at the same time without shutting down the
> whole network. In order to perform a gradual, rolling upgrade, end
> points are updated to include both SHA-512 and SHA-256 fingerprints in
> SDP descriptions. Older end-points will still accept keys used for
> connections based on older SHA-256 fingerprints. Newer end points will
> accept keys used for connections based on either SHA-256 or SHA-512
> fingerprints. Once all end points in the network are updated to support
> SHA-512 fingerprints, another rolling update is started to remove
> support for SHA-256 fingerprints. After this update completes only
> newer, SHA-512 based fingerprints will be used in the network.

Still, what is the attack? The following come to mind:

1) capture the encrypted signaling and media. Then attack it offline to 
decode the media.

2) insert a MITM into the signaling path. Change the signaling to 
redirect the media so that it can be decoded and changed in realtime.

For (1), if the signaling can be decrypted (or if it wasn't encrypted) 
then AFAICT it doesn't matter what hash algorithm is used for the 
fingerprint. If the signaling can't be decrypted more easily than the 
media then the fingerprint hash is irrelevant.

For (2), if you are going to install a media relay that decodes/encodes, 
and you can manipulate the signaling, then again I don't see how it 
matters what hash function is used for the fingerprint.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 15:20:09 -0400

On Mon, Mar 21, 2016 at 2:25 PM, Paul Kyzivat <[email-masked]> wrote:

> 2) insert a MITM into the signaling path. Change the signaling to redirect
> the media so that it can be decoded and changed in realtime.
>
> fingerprint. If the signaling can't be decrypted more easily than the media
> then the fingerprint hash is irrelevant.
>
> and you can manipulate the signaling, then again I don't see how it matters
> what hash function is used for the fingerprint.
>

The attack is that you reroute media traffic to a compromised location
without changing signaling. This can be done by compromising the service
provider router or by generating ARP packets that redirect traffic for a
particular IP to a different device on the local network. After that you
generate your own certificate in such a way that it has the same hash
signature as the certificate used by the monitored party. Then you decode
the traffic using your certificate and send it to the end point using their
certificate while listening or recording the media.

Amusingly enough I saw this exact attack happen with MD5.
_____________
Roman Shpount