IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 25 April 2016 19:26 UTC

Return-Path: <christer.holmberg@ericsson.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 8507F12D6CC for <mmusic@ietfa.amsl.com>; Mon, 25 Apr 2016 12:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 r48m2z9gMih5 for <mmusic@ietfa.amsl.com>; Mon, 25 Apr 2016 12:26:14 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4169A12D6C8 for <mmusic@ietf.org>; Mon, 25 Apr 2016 12:26:14 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-a1-571e6f540bdc
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.8E.18043.45F6E175; Mon, 25 Apr 2016 21:26:12 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 21:26:12 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] 4572 update: forbid weak hashes?
Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///n5gCAACIUsP//4eqAgAB6NgCAASWpgIAARJyAgBqMZgD//+CxgAAMKyYw///qVAD//90jgA==
Date: Mon, 25 Apr 2016 19:26:10 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37F7CF63@ESESSMB209.ericsson.se>
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> <CAD5OKxv57rSx1wok=d04k1gVaDz0188ijhc97XwZepdX2u9tVA@mail.gmail.com> <D343F764.77D5%christer.holmberg@ericsson.com> <CAD5OKxtMVNTSnyACRmA6NUEtAam0Xc=-cRD_2BCQjfH6Kekhjw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> <CAD5OKxuh0CQDA=jNt1nSQ03mQKuD3-V09KOT-rEgEakRBP1Ckw@mail.gmail.com>
In-Reply-To: <CAD5OKxuh0CQDA=jNt1nSQ03mQKuD3-V09KOT-rEgEakRBP1Ckw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F7CF63ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7hG5Ivly4waJP6hZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyNnXfYCw4EFFxYPE8pgbG jrAuRk4OCQETib6VR9kgbDGJC/fWA9lcHEICRxgl7rdvYoVwljBK/Hl2g6mLkYODTcBCovuf NkiDiICqxN/vk5lAbGYBX4mXC74wg5QIC5hJXDseC1FiLvGzoZEFwq6TeHu/gRHEZgFqfTR/ H9hEXqDWOd/UIDa9Y5VYef0k2EhOgUCJvh0XwWxGoNu+n1oDtUpc4taT+UwQNwtILNlznhnC FpV4+fgfK4StJLFi+yVGiPp8iRNXm8FsXgFBiZMzn7BMYBSdhWTULCRls5CUzQI6j1lAU2L9 Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMvoNb flvtYDz43PEQowAHoxIP7wJO2XAh1sSy4srcQ4wSHMxKIrxLcuTChXhTEiurUovy44tKc1KL DzFKc7AoifPmRP4LExJITyxJzU5NLUgtgskycXBKNTAGpHlkbLlzhNHf+UP6jDd1Wjs/vzA5 7PzopYnxkRdJTfGrv1pznlD62RAXFWPwSrSI09Kmf/Uk6ZdL0mTubFg7b0MUzyeFWjbutVVC h2uPafq/sPk0b1lAidIZLYOelfYHn84+uGr9ornKC7MN9Bo45kqc65C7Wj3nx9OoYhVlG3FV 09B/RzcrsRRnJBpqMRcVJwIAxwHn4LoCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/JuIF_WHdCSB9PhxNLpEdyggP_ok>
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: Mon, 25 Apr 2016 19:26:16 -0000

So, does anyone object to the proposal: no matter how many certificates (and associated fingerprints) the SDP contains, as long as there is *one* hash (that the receiver supports and consider secure enough) matches the certificate, things are good.

(I agree that is also the best (only?) solution from a backward compatibility perspective)

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 25 April 2016 22:19
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
Subject: Re: [MMUSIC] 4572 update: forbid weak hashes?

On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>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 :)


I agree with trying to keep things simple. This means agreeing to something that is secure enough (one match for anything you consider secure is enough) vs trying to create something that is more secure (one fingerprint for each offered fingerprint hash algorithm must match).

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email