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

[Paul Kyzivat <[e-mail]>]

Roman,

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

On 3/21/16 10:55 AM, Roman Shpount wrote:
> 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.

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