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

Christer,

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.

Regards,

_____________
Roman Shpount

On Mon, Apr 25, 2016 at 9:38 AM, Christer Holmberg <
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> on behalf of Roman Shpount <
> roman@telurix.com>
> Date: Friday 8 April 2016 at 22:14
> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
> Cc: "mmusic@ietf.org" <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>
> 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>> 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
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>