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

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
wrote:

> On 3/21/16 6:37 AM, Martin Thomson wrote:
>
>> On 21 March 2016 at 20:55, Roman Shpount <[e-mail]> 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
>