Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

RJ Atkinson <rja@extremenetworks.com> Wed, 31 December 2008 19:50 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 4749D3A6A1D; Wed, 31 Dec 2008 11:50:14 -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 16AA43A6A00 for <saag@core3.amsl.com>; Wed, 31 Dec 2008 11:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.263
X-Spam-Level:
X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 CFEjGZok6wlx for <saag@core3.amsl.com>; Wed, 31 Dec 2008 11:50:13 -0800 (PST)
Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id E1B4C3A6808 for <saag@ietf.org>; Wed, 31 Dec 2008 11:50:12 -0800 (PST)
Received: from [10.30.20.71] ([72.84.80.181]) by vms173005.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KCR00A7HB2UXPN5@vms173005.mailsrvcs.net> for saag@ietf.org; Wed, 31 Dec 2008 13:49:46 -0600 (CST)
Date: Wed, 31 Dec 2008 14:49:41 -0500
From: RJ Atkinson <rja@extremenetworks.com>
In-reply-to: <FAD1CF17F2A45B43ADE04E140BA83D489365D7@scygexch1.cygnacom.com>
To: saag@ietf.org
Message-id: <C35F257D-7F83-4CF4-8262-981A85A7C196@extremenetworks.com>
MIME-version: 1.0 (Apple Message framework v930.3)
X-Mailer: Apple Mail (2.930.3)
References: <E1LHplH-0006Xw-V6@wintermute01.cs.auckland.ac.nz><7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> <FAD1CF17F2A45B43ADE04E140BA83D489365D7@scygexch1.cygnacom.com>
Cc: cfrg@irtf.org
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
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

On  31 Dec 2008, at 14:14, Rich Graveman wrote:
> For an expert, authoritative, and incredibly up-to-date tutorial on
> the state of hash functions, go to http://www.inscrypt.cn/, get the
> invited talks, and see the one by Preneel. If the intro material is
> boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not
> quite in the same boat.

Those talk about the hash functions generally, but they do not
really address the question specifically *as such functions are
actually employed by some number of IETF protocols*.  (And just
to be clear, I'm thinking quite broadly -- well beyond the narrow
realm of hashes as used by certificates.)

A collision attack on some hash function f() might or might not
be an issue if f() is used in any of several different modes,
for example.

> Unfortunately, the ways cryptologists look at these things and the
> ways the IETF uses them are not always the same, so there is more work
> to do.

Right.  What I was asking for, specifically, was analysis that
considered the various ways that various IETF protocols actually
use them -- not abstract concerns that might or might not relate
to the way they are actually used by various IETF protocols.
("ways" means not just deployment model, but also the mode of
operation).

One could easily imagine, for example, that some uses of these
algorithms might be viewed as entirely fine, with other uses
being clearly unsuitable, with a wide range of possibilities
in between those two extremes.

It is this specific analysis that is missing, needed, and would be
most valuable to various IETF WGs -- if available in a public
document (ideally an Informational RFC, developed jointly as
a public group effort, such as by the IRTF CFRG, and including
full references to the public literature).

My apologies for somehow being unclear in my earlier note.

Thanks,

Ran
rja@extremenetworks.com


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag