Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

Russ Housley <housley@vigilsec.com> Tue, 30 December 2008 22:17 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 956C128C2E6; Tue, 30 Dec 2008 14:17:19 -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 84FD828C2E6 for <saag@core3.amsl.com>; Tue, 30 Dec 2008 14:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Level:
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 flN1z0s4lOGb for <saag@core3.amsl.com>; Tue, 30 Dec 2008 14:17:17 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id A30B328C1F1 for <saag@ietf.org>; Tue, 30 Dec 2008 14:17:17 -0800 (PST)
Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 17:12:02 -0500
To: RL 'Bob' Morgan <rlmorgan@washington.edu>, Paul Hoffman <paul.hoffman@vpnc.org>
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <alpine.LFD.1.10.0812301313570.2644@perf.cac.washington.edu >
References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <p0624081dc5802a331eac@[10.20.30.158]> <alpine.LFD.1.10.0812301313570.2644@perf.cac.washington.edu>
Mime-Version: 1.0
Message-Id: <20081230221717.A30B328C1F1@core3.amsl.com>
Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org
Subject: Re: [saag] 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

>>Regardless of that, the authors of the MD5 paper are correct: trust 
>>anchors signed with MD5 are highly questionable as of today (well, 
>>actually, since they published their last paper). Hopefully, the 
>>maintainers of the popular trust anchor repositories (Microsoft, 
>>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and 
>>MD2!) as soon as possible.
>
>This is a different claim than "CAs should stop issuing certs with 
>MD5 signatures", which is what I as an amateur take away from a 
>quick scan of the material.  Obviously MD5 is suspect in various 
>ways, but does this new work lead to the conclusion that MD5-signed 
>roots are untrustworthy today?

We recommended a migration (walk, don't run) away from MD2, MD4, and 
SHA-1 toward SHA-256 a few years ago.  MD2 and MD4 generate 128 bit 
hash values; even without the attacks, these are getting to be too 
small.  SHA-1 has been shown to be weaker than its design goal, and 
the 160 bit hash value will be getting too short in a couple of 
years.  We recommended SHA-256 while fully recognizing that NIST was 
starting a hash competition, and that we might recommend the winner 
of that competition as the successor to SHA-256.

I still strongly encourage the migration to SHA-256.

The use of the random bits in the serial number are insurance against 
similar problems being found in other hash functions.  This insurance 
will hopefully provide time to migrate to another hash function when 
cryptanalysis begins to show flaws in any future hash function.

Russ 

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