Re: [saag] RFC analyzing IETF use of hash functions [was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate]

Sean Turner <turners@ieca.com> Tue, 06 January 2009 03:20 UTC

Return-Path: <saag-bounces@ietf.org>
X-Original-To: saag-archive@ietf.org
Delivered-To: ietfarch-saag-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB983A65A5; Mon, 5 Jan 2009 19:20:45 -0800 (PST)
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381363A65A5 for <saag@core3.amsl.com>; Mon, 5 Jan 2009 19:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.291
X-Spam-Level:
X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DEIc295qrCX for <saag@core3.amsl.com>; Mon, 5 Jan 2009 19:20:43 -0800 (PST)
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id 17A373A63D2 for <saag@ietf.org>; Mon, 5 Jan 2009 19:20:42 -0800 (PST)
Received: (qmail 50388 invoked from network); 6 Jan 2009 03:20:30 -0000
Received: from unknown (HELO ?192.168.1.2?) (turners@71.191.9.174 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Jan 2009 03:20:29 -0000
X-YMail-OSG: Z63BL6oVM1m.U4ByW.ZtpB8LfadDgSTjCSmqUkj2rNSI0CFaqLyAOG3Fmnfq6SGVjVCCOPxLGbfMNfJdNH06leCCa2AYTSU7O9hlDmLoBPHn3bx5T4estdF1LorH6mAtva2yvcWIbb4jnYUkp2kyS.OIKqmKOXF_AU3Gjr4blM5PFfn6CUeLQ5ag97NaCewnoJKasS70kLkH5sq77EwY.FeakfqiXlyHZEYh2YTdNM3pteyOd_OY19706R1v084-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4962CE09.5010007@ieca.com>
Date: Mon, 05 Jan 2009 22:20:41 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: David McGrew <mcgrew@cisco.com>
References: <E1LHplH-0006Xw-V6@wintermute01.cs.auckland.ac.nz> <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com>
In-Reply-To: <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com>
Cc: cfrg@irtf.org, saag@ietf.org
Subject: Re: [saag] RFC analyzing IETF use of hash functions [was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate]
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org

Dave,

When the S/MIME WG penned 
http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we added an 
appendix that addresses where hashes are located in CMS's SignedData and 
the attacks against those hashes.  I'd be willing to help craft any 
other wording necessary for S/MIME|CMS.

spt

David McGrew wrote:
> Hi Ran,
> 
> I think it is a great idea to document the IETF applications/uses of 
> hashing, and the attacks against particular uses of hashing.  It would 
> make a great CFRG informational RFC, if we can find volunteers to 
> contribute to and edit it.  I offer to review it.
> 
> David
> 
> On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote:
> 
>>
>> [Distribution trimmed slightly to reduce cross-posting and improve SNR.]
>>
>> On  30 Dec 2008, at 20:20, Peter Gutmann wrote:
>>> The current MD5 attack is very cool but there's no need to worry about
>>> bad guys doing much with it because it's much, much easier to get
>>> legitimate CA-issued certs the normal way, you buy them just like
>>> everyone else does (except that you use someone else's credit card
>>> and identity, obviously).
>>
>>
>> Two thoughts:
>>
>> 1) Protocol Issues
>>
>> The IETF ought to be thinking about a wide range of IETF protools
>> in the same way that Peter thinks about CA security issues above.
>>
>> For some IETF protocols, for example all of the IGP authentication
>> extensions (excepting RFC-2154, AFAICT), active non-cryptographic
>> attacks are feasible (if not yet seen in the deployed world, AFAICT)
>> that are much easier than *any* cryptographic attack.  Again, and
>> only by way of example, RFC-4822 discusses some of these that are
>> specific to RIPv2 authentication.
>>
>> For protocols where non-cryptographic attacks are feasible AND
>> are lower cost than a cryptographic attack, really it does not make
>> much difference what cryptographic algorithm gets deployed by a user
>> -- and the IETF's focus should be on improving the underlying 
>> authentication mechanism BEFORE worrying about which cryptographic
>> algorithms are being deployed.
>>
>> Attackers are generally both smart and lazy, so they won't waste
>> time on an expensive cryptographic attack when a lower effort
>> non-cryptographic attack exists.
>>
>>
>> 2) Hash algorithm analysis
>>
>> It would be very helpful if a *set* of mathematicians/cryptographers
>> could jointly put together a summary of the known attacks on all
>> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1,
>> SHA-2, others), *including references to the published literature*.
>>
>> Ideally, this analysis would also include discussion of whether those
>> attacks apply for those same algorithms when used in the modes employed
>> by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5
>> or RIPv2 MD5, HMAC-Hash, and so forth).
>>
>> This would be most useful to have as an Informational RFC,
>> and SOON, so that IETF WGs could have some "consensus" document
>> to refer to -- and to cite explicitly -- if any IETF WGs decide
>> to make hash algorithm recommendations or decisions.
>>
>> I don't understand IRTF process details perfectly, but perhaps
>> the CFRG chairs might undertake creating such a document as a
>> near-term official CFRG group project.
>>
>> Yours,
>>
>> Ran
>> rja@extremenetworks.com
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag