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

Roman Shpount <roman@telurix.com> Fri, 08 April 2016 19:14 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3612D1BC for <mmusic@ietfa.amsl.com>; Fri, 8 Apr 2016 12:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcDnCJ2o745b for <mmusic@ietfa.amsl.com>; Fri, 8 Apr 2016 12:14:30 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B5D12D0B0 for <mmusic@ietf.org>; Fri, 8 Apr 2016 12:14:29 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id g185so143137052ioa.2 for <mmusic@ietf.org>; Fri, 08 Apr 2016 12:14:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LxTdumfX5b1oC6F5sPjln7vdMqVPMivPxO4IFh6x3UQ=; b=ltxYnjiEdy4EteNpC9AnyU8l2JISAzNPM9/nPY2reJl5DHxtrT5VZb5W1uGhonSJEH VK7fa6C1lUMGPJ2n95Xmg6Hqc5BTLW1clQnQbk3Y3CLq7u3K3YYsD0aIDKaBLO8mmr7l cdGtcrbxKZal5BbzorbmM7t0WaXOjsxJ3V3J2maGT5v3TwS9lE8csYL7oiOJri56std8 ZYDGUgv/jL6IKn0Q3GFJ8oGuMdv6g/RtWFBF4qE7gVCohe9HMKLef6GxCgrKxJ0uTkTy fDmTAa6ZBKogM45iZlPfq1+BacqILD87gX8HdE4nguTydV88HRN9imvQW83A2eXxT7jM NcQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LxTdumfX5b1oC6F5sPjln7vdMqVPMivPxO4IFh6x3UQ=; b=aw+lBukFb06NTyHkCla8/hX1dDfCzuCi70NiMCcud7b7IBB5MAkbjlkNGx8EtNiSVM Fqhmiy84M0x/nBsoZNs7RoZaH6z6lIWXqSVNMBLYwW3+0f49hXcbhBtjWbSNTpKg1mXM HZKsbIOTmmiGewbe1g0nYUoWepPs4EeCcPU39mQzc2LRO6EpUQ8caiiCBspzKUHEeDOo 5a1AItKDdYhXk/bOjdfQi60C+cBWiHaPm+IBvw8mVQq+CnWmcZrhHb0ls/RcSrrl5Rlu lXoWOTIG5LMAkMMLlG68Si0881HuoV/tZgjgu+jnbNvhunkP8q9nRuYQs8YNi+5XFTWY 77GA==
X-Gm-Message-State: AOPr4FXhHLJTWH0abhUX76A3eCI7tjpzt7F9NkmPm/I0oL5Dz4FwtCJ+h52Q+ZbjeBEDSw==
X-Received: by 10.107.59.80 with SMTP id i77mr497651ioa.36.1460142869058; Fri, 08 Apr 2016 12:14:29 -0700 (PDT)
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id cl9sm2822586igc.10.2016.04.08.12.14.28 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 12:14:28 -0700 (PDT)
Received: by mail-io0-f178.google.com with SMTP id 2so143134290ioy.1 for <mmusic@ietf.org>; Fri, 08 Apr 2016 12:14:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr11442591ioe.145.1460142867950; Fri, 08 Apr 2016 12:14:27 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 12:14:27 -0700 (PDT)
In-Reply-To: <5707C985.5060809@alum.mit.edu>
References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <CABkgnnU0qwkUGLv4rkax3hbat9Fb6kXDH9TKZv3MukepN7PkmQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <CAD5OKxtb4Ss8BzeBDMUs7V7Yfx3YC0U53JmhZLen1C2+FkyGog@mail.gmail.com> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu>
Date: Fri, 08 Apr 2016 15:14:27 -0400
X-Gmail-Original-Message-ID: <CAD5OKxv57rSx1wok=d04k1gVaDz0188ijhc97XwZepdX2u9tVA@mail.gmail.com>
Message-ID: <CAD5OKxv57rSx1wok=d04k1gVaDz0188ijhc97XwZepdX2u9tVA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="001a1140d71ef743cc052ffe0065"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/XL0qdO-3tyq5w90EqJu27gBnvp4>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4572 update: forbid weak hashes?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 19:14:32 -0000

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
>