IETF Logo Mail Archive

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

Roman Shpount <roman@telurix.com> Thu, 07 April 2016 20:55 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 274B812D135 for <mmusic@ietfa.amsl.com>; Thu, 7 Apr 2016 13:55:07 -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 mXWkgLDboWUH for <mmusic@ietfa.amsl.com>; Thu, 7 Apr 2016 13:55:05 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 2C10812D16F for <mmusic@ietf.org>; Thu, 7 Apr 2016 13:55:05 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id 2so108915742ioy.1 for <mmusic@ietf.org>; Thu, 07 Apr 2016 13:55:05 -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=4UGFasJiCW6tg/R9u1q4XQXPLVIvyiqeaz45iZtzvjI=; b=PcwSJ6JFaSyKNDK7TRPDzo0x7JL9dPbTUR31icdtfgPQLzTkt7AUb42tpil7BuiFWB rKC0cpmhSYGvpCpnZOkgG2RA8aJ8Y1W+7sFxU7fCV3Hx3oYyY4lgLroM0vo6bx5LilQc yAA0opQ57ujX9/Uyjn4hXSPPHs7c0gmGnj+DSYsUhHxry5XkK97Uul1A6/6kOwSVa1Tx uTD05JUC13d2mVk7VwX5M7ixf5rCpx0B8FymqmWxfrYsUFCOx9Eip5LoEfD/238ZQq19 rS6eQo4i+o4pxIHbTL4mmzYpPG7+ya/OVhdEGQMr6ohj6HN7UejEUpcQOsM3r7dCz1bj QlMw==
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=4UGFasJiCW6tg/R9u1q4XQXPLVIvyiqeaz45iZtzvjI=; b=Rxn6Jm7c4KJz2ZL1/c6/28hDV06IuqUHgFqcjTikUm1EnwrSnRoG2RnLxFTrk6Fay2 PboMS6+BsRDgCvj5LJHfU9K5VzETwyczXOibfrWhOW6KEOnfcm6OEh5mDDI6FK6FlZQU PFzu/5aXq0Kuo/Fm+5Kdt2n4EUKX6EmWzT4WecsilrGr6omKJ/9K9VL/0dJsDhWcB2mt IuBmdO8VcfVnn/zsBI0Ty+L4O2KfMmxQ7iudT8UdMdXNw4ubEiLQ48crsS+oUOQFMK2P nIOcfbg0PRoBPmJTEVe2c/+hFObNakefEYvU28ysfLqGQYVOw21DI9YiLDrM7WRxwxQk Nv0w==
X-Gm-Message-State: AD7BkJK6ghXfvZacQmdp0ORK8WZEPBGGBXKFKkY4HBufIgO6FNTu8QDq6wI0OsVFKx9cog==
X-Received: by 10.107.10.167 with SMTP id 39mr6420128iok.152.1460062504357; Thu, 07 Apr 2016 13:55:04 -0700 (PDT)
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id ip3sm4495562igb.14.2016.04.07.13.55.03 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 13:55:03 -0700 (PDT)
Received: by mail-io0-f171.google.com with SMTP id o126so86539503iod.0 for <mmusic@ietf.org>; Thu, 07 Apr 2016 13:55:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr5638869ioe.145.1460062503318; Thu, 07 Apr 2016 13:55:03 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 13:55:03 -0700 (PDT)
In-Reply-To: <CABkgnnXApcn6K0fEEgrTNCOtdPDJeWJnhkmMzm+7b2jUt1nN+A@mail.gmail.com>
References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <CABkgnnU0qwkUGLv4rkax3hbat9Fb6kXDH9TKZv3MukepN7PkmQ@mail.gmail.com> <57067AFE.9070704@alum.mit.edu> <CAD5OKxtX9HLWJJgKsG7hNJbRB1muS+fe8Pnnm=g4+=ryPyMN+A@mail.gmail.com> <5706B499.9030209@alum.mit.edu> <CAD5OKxu_Ok2Cpb6Zvim4RtOpab3UY1xMWrJtODVHiqJBR_vfJA@mail.gmail.com> <CABkgnnWS030+7xLMdbd+p0bh3805UtRB5fYkOmGuxPcdHLh-1w@mail.gmail.com> <CAD5OKxsVZqOj-HG7_vN4KS+E6=mKurGew=kkRv10u=CJe6QZwQ@mail.gmail.com> <CABkgnnXApcn6K0fEEgrTNCOtdPDJeWJnhkmMzm+7b2jUt1nN+A@mail.gmail.com>
Date: Thu, 07 Apr 2016 16:55:03 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsQZe_nNGF421sAw1tr5qeEuxG7SBmAaY7oo8E0U-GvCQ@mail.gmail.com>
Message-ID: <CAD5OKxsQZe_nNGF421sAw1tr5qeEuxG7SBmAaY7oo8E0U-GvCQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a1140d71edc677f052feb4a6a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/CGb-jVc17yOdNlxxBmCrFSd10bY>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Thu, 07 Apr 2016 20:55:07 -0000

On Thu, Apr 7, 2016 at 4:09 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 7 April 2016 at 16:54, Roman Shpount <roman@telurix.com> wrote:
> > Let me try to explain this again why this will not work. Consider that
> RTP
> > and RTCP can come from two different sources (devices) which will use
> > different DTLS associations for each component, use different
> certificates,
> > and potentially support different sets of hash functions. Because of
> this,
> > the fact that RTP device supports SHA-256 does not mean that RTCP will
> use
> > it or support it.
>
> How is that relevant?  If the RTCP endpoint doesn't support X, then it
> uses what it can.
>

Let me clarify, let's say RTP device supports SHA-256 and SHA-1 and RTCP
device supports SHA-1 only. The combined offer from these two devices will
have an m= line with 3 fingerprints: SHA-256 and SHA-1 fingerprint for RTP
device certificate and SHA-1 fingerprint for RTCP device certificate. When
the other end point gets DTLS association from RTP device, two fingerprints
will match (one SHA-1 and one SHA-256). When remote end point gets DTLS
association from RTCP device only one SHA-1 fingerprint will match. If I
understand your proposal correctly this will cause DTLS association for
RTCP to be rejected since it did not match a single SHA-256 fingerprint.
This is definitely undesirable.

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email