IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 07 April 2016 14:05 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 8BE9312D104 for <mmusic@ietfa.amsl.com>; Thu, 7 Apr 2016 07:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-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 LPOnQAFuyR43 for <mmusic@ietfa.amsl.com>; Thu, 7 Apr 2016 07:05:05 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BCF12D501 for <mmusic@ietf.org>; Thu, 7 Apr 2016 07:05:05 -0700 (PDT)
X-AuditID: c1b4fb2d-f79c06d000005960-92-570668dff6ac
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.FA.22880.FD866075; Thu, 7 Apr 2016 16:04:15 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 16:04:14 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Thread-Topic: 4572 update: forbid weak hashes?
Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///iCYCAACYSAA==
Date: Thu, 07 Apr 2016 14:04:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37F27D03@ESESSMB209.ericsson.se>
References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7FAC6369-90CA-4C50-9EC6-EF7E835F9DC4@vidyo.com>
In-Reply-To: <7FAC6369-90CA-4C50-9EC6-EF7E835F9DC4@vidyo.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdWJc/ky3c4OJpZYv9i88zW0xd/pjF gcljyZKfTB5tz+6wBzBFcdmkpOZklqUW6dslcGXsvrmRreAVZ8XWX8eZGhhPcHYxcnBICJhI tE1j7mLkBDLFJC7cW8/WxcjFISRwhFHi8o9TTBDOIkaJlvttzCANbAIWEt3/tEEaRAQ0JC4+ +8AGYjMLyEjMONvIBGILC+hKbJg6lwmiRk/i17TpLCCtIgJOEqu2ZoCEWQRUJM42fWMFCfMK +Ers+uwAsWkzo0T7rRdgrZwCthId+1+A3cYIdNv3U2uYIFaJS9x6Mp8J4mYBiSV7zkPdLyrx 8vE/VghbSWLF9kuMIPOZBTQl1u/Sh2hVlJjS/ZAdxOYVEJQ4OfMJywRGsVlIps5C6JiFpGMW ko4FjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQLj5uCW37o7GFe/djzEKMDBqMTDq7Cf NVyINbGsuDL3EKMEB7OSCO+6FLZwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rw5kf/ChATSE0tS s1NTC1KLYLJMHJxSDYw9lc2GZY2yf1Y3nFUPvbdwK8tvmdRt91WusPLert/Acbfb/oLPZb/r rw5HP0pQS55n13Ys+P6itGnndYR1ahnnMfOGb2o4OJ1JfUFUaB6ruKXVjHN7LN3qTpX8S1q3 POpZ5sEblxKPf6rd38a7pGHThbpZO607rxUKszRoyUWKRC48qSxg+k6JpTgj0VCLuag4EQBJ Gqa8lwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/o5KSHkouE17n5sm52SR-hRT5zgw>
Cc: mmusic <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: Thu, 07 Apr 2016 14:05:14 -0000

Hi,

>>> For the RFC 4572 update, I think we should add that receivers MUST NOT match on fingerprints >>> computed with weak hashes, and senders SHOULD NOT send them.
>>> 
>>> If we do this, it removes some of the questions about “do you need to verify a fingerprint for every >>> hash algorithm, or only one.”
>> 
>> What about saying that one MUST match on the strongest hash received? 

Clarification: of the received hashes, the strongest one that the receiver support

>> Then, if you only receive a weak hash, isn't it still better to match than doing nothing?
>
>Not if the hash is so weak it’s not secure, and a plausible implementation wouldn’t be using it.  Such >an offer might be a bid-down attack of some sort.  You’re better off rejecting the stream.

Do we let the application decide what is considers "too weak", or do we want to specify something?

Regards,

Christer

v2.23.0 | Report a Bug | By Email