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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Thu, 08 January 2009 04:21 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 7D1193A684C; Wed, 7 Jan 2009 20:21:44 -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 B4C6C3A684C for <saag@core3.amsl.com>; Wed, 7 Jan 2009 20:21:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.816
X-Spam-Level:
X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fkOXn5RN-r2N for <saag@core3.amsl.com>; Wed, 7 Jan 2009 20:21:43 -0800 (PST)
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id AC5133A681F for <saag@ietf.org>; Wed, 7 Jan 2009 20:21:40 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9E02319A23; Thu, 8 Jan 2009 17:21:26 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPAH1uc8SBNx; Thu, 8 Jan 2009 17:21:26 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 987C719A2C; Thu, 8 Jan 2009 17:21:23 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6D18E1BE4002; Thu, 8 Jan 2009 17:21:22 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1LKmOY-0001mL-AH; Thu, 08 Jan 2009 17:21:22 +1300
From: pgut001@cs.auckland.ac.nz
To: pgut001@cs.auckland.ac.nz, v.paz@uq.edu.au
In-Reply-To: <6C62167D152FAD4F91D2D6C8392D1DF005B58E85@UQEXMB1.soe.uq.edu.au>
Message-Id: <E1LKmOY-0001mL-AH@wintermute01.cs.auckland.ac.nz>
Date: Thu, 08 Jan 2009 17:21:22 +1300
Cc: tmiller@mitre.org, ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org

"Viviani Paz" <v.paz@uq.edu.au> writes:

>1- browser vendors strongly encouraging the CA organisations vulnerable to
>this problem (using MD5) to get their act together. I'd like to see the
>browser vendors giving them a cut off timeframe and remove these root certs
>from their trust lists for good.

The problem with this is that it's not going to be so easy to tell who's at
fault, the first MD5 cert may not appear until several levels down the food
chain so there's no way to tell whether a particular root ends in an MD5 cert.
And if you do remove a root because some unrelated party five steps down the
food chain uses MD5 I can see lawsuits happening...

>2- meanwhile browser vendors could issue a warning when certificates relying
>on MD5 are in use, this is simpler to be done and shame goes a long way
>sometimes. It doesn't resolve the problem, but sets things in motion.

That one would definitely work, but has the downside of penalising innocent
customers of the CA that issued the cert and not the CA that made the mess.
You'd have to convince the CA to issue free replacements for this to work,
possibly by framing the warning message in terms of the CA using unsafe
practices rather than the site itself being insecure.  Even then it's a rather
indirect approach that doesn't really target the guilty party since you're
scaring the user who is supposed to exert pressure on the site which is then
supposed to pressure the CA for a fix.

(This is one of those great all-care-and-no-responsibility situations, the CAs
can pretty much screw up as much as they want but there's no real
repercussions for anyone because of the collateral damage issue.  The debate
on the Mozilla forums shows this, there's all manner of knee-jerk reactions
possible to make an example of someone convenient but none of them really get
to the root of the problem).

Peter.

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