Re: [MMUSIC] 4572 update: forbid weak hashes?

Hi,

>There is no indication what fingerprint applies to what certificate in SDP fingerprint attribute. >The rule should be if connection is established a certificate which matches at least one hash >that you consider secure, the connection should be accepted. If you would make it more >complicated, this will likely break backwards interop or would require changes to >fingerprint/DTLS/certificates.

I don’t want to make things complicated – I want to agree on something, update the draft based on that, and go WGLC :)

Regards,

Christer

On Mon, Apr 25, 2016 at 9:38 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

I think option 1) does not support hash agility – which is one of the main reason from sending multiple fingerprints to begin with – as it assumes that the sender and receiver will support the same hash functions.

Option 2) seems to be what Cullen also suggested: as long as there is at least one fingerprint (calculated using a has function which the receiver considers secure enough) that matches the DTLS association. So, in general I support option 2).

However, we need to keep in mind that there may be fingerprints sent for multiple certificates. Do we need to mandate at least one match per cerfificate?

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
Date: Friday 8 April 2016 at 22:14
To: "pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>" <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>
Cc: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] 4572 update: forbid weak hashes?

I just wanted to re-iterate the question. We have two options:

1. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with each function must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match at least one SHA-1 and one SHA-512 fingerprint.

2. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with any hash function which is considered secure enough must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match one of either SHA-1 or SHA-512 fingerprints.

Option 1 has a benefit of being more secure since it provides the combined secure of individual hash functions. It does put additional restrictions how equipment can be combined into producing a single m= line. For instance if fingerprints from two servers are combined into a single m= line and it is not known in advance which one will be used, both servers will need to always support the same hash functions and be updated at the same time.

Option 2 is less secure since it is only as secure as the least secure hash. On the other hand option 2 allows to be more flexible in how equipment is combined to form the single m= line. Two servers in above example, for instance, can support different hash functions.

I would ask the group to state their preferences.

I prefer option 2 but can live with option 1.

Regards,

_____________
Roman Shpount

On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
I don't have a horse in this race. I think those of you who do need to finish deciding what the rules are for multiple fingerprints, and then write the result into the draft update. Clearly it is ambiguous at the moment.

        Thanks,
        Paul

On 4/7/16 5:37 PM, Cullen Jennings wrote:

On Apr 7, 2016, at 11:20 AM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>
<mailto:roman@telurix.com<mailto:roman@telurix.com>>> wrote:

You should check all the hashes you consider secure and if any one of
them matches the DTLS association certificate, accept the media.

+1

This allows us to do things like include hash for two servers even when
you re not sure which server will actually be used.

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic