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

Philipp Guehring <philipp@cacert.org> Mon, 05 January 2009 06:54 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 CA99728C12C; Sun, 4 Jan 2009 22:54:28 -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 CC10D3A6AA7 for <saag@core3.amsl.com>; Wed, 31 Dec 2008 20:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.443
X-Spam-Level:
X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545]
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 CxqzJdYiA+Jk for <saag@core3.amsl.com>; Wed, 31 Dec 2008 20:27:28 -0800 (PST)
Received: from email.cacert.org (gate.cacert.nl [213.154.225.228]) by core3.amsl.com (Postfix) with ESMTP id 915A23A6AA5 for <saag@ietf.org>; Wed, 31 Dec 2008 20:27:28 -0800 (PST)
Received: from [10.0.0.5] (212-183-47-3.adsl.highway.telekom.at [212.183.47.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: philipp) by email.cacert.org (Postfix) with ESMTP id DF7A094067; Thu, 1 Jan 2009 04:01:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cacert.org; s=mail; t=1230782488; bh=2t/tyH0w7XZjAia3mojkwpnUeGm+G84pm/A/yvQQ+Vo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hRCGgbx3q6L5 GtnIaQxGouk0Ev4K2dR+yGldANB4XbVSbh4mnlTeBjoCRbbSlirIBAk8FuVAgNcQILo LiU1QS1OKboucovZ5nurXbd/t4NSyy7ldvlhEobbCe4IyN9tYHv7IdQ91zyI6kibgTk eLiX60bhDpm31cQjgpaqQnjuw=
Message-ID: <495C401D.30507@cacert.org>
Date: Thu, 01 Jan 2009 05:01:33 +0100
From: Philipp Guehring <philipp@cacert.org>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: Santosh Chokhani <SChokhani@cygnacom.com>
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> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> <FAD1CF17F2A45B43ADE04E140BA83D4893657C@scygexch1.cygnacom.com>
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D4893657C@scygexch1.cygnacom.com>
X-Enigmail-Version: 0.95.7
X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800
Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org

Hi,

> CAs should have stopped issuing certs with MD5 signatures 4 years ago,  
> when the first practical attacks on MD5 were published.

That's what nearly all of the CA's actually did back then.
But due to the all-for-one and one-for-all problem, that wasn't enough,
and it seems that our auditors forgot to care about it.

> Now it would be more correct to say that "relying parties should treat  
> as invalid any certificate chain that contains an MD5 (or MD2, MD4)  
> signature"

Yes, except for the root certificates / trust anchors.

> Since in the HTTPS context the relying parties are the browsers, it  
> falls to the vendors (if Microsoft leads, everyone will follow) to, as  
> Paul said, yank the trust anchors.

The trust anchors are the wrong place to attack the problem.

> It should be noted, though, that yanking the trust anchors is not  
> enough. You really should change the relying party to not recognize  
> this algorithm. Otherwise, it's perfectly valid for a CA whose  
> certificate is signed with SHA1 to sign an intermediate CA certificate  
> with MD5 (although they usually don't do that, I hope)

I also thought so, but then I realized that if we invalidate MD5
completely, then we would also invalidate root certificates that are MD5
self-signed, which isn't a security issue. So that would give lots of
unnecessary false-positives.

I would like to propose the following idea:

We should define a date for expiring MD5 in certificate chains for the
Internet. I would suggest the 1. June 2009, which is 6 months from now.
All software should present or log warnings in case a MD5 signature is
detected in the certificate chain (except for the self-signatures of the
root certificates) before the 1. June 2009.
The warning should state that this certificate is considered insecure
and will stop functioning on 1. June 2009.
After 1. June 2009, SSL- and digital-signature-creation applications
should treat MD5 signatures should as invalid.
After 1. June 2009, Digital signature verification applications should
warn the user that MD5 signatures have been abandoned on 1. June 2009

I think if we can agree on a date to expire MD5, and inform the media
and the users through the warnings about the expiry date

There is already a Firefox extension that warns about the certificates:
http://codefromthe70s.org/sslblacklist.aspx

Best regards,
Philipp Gühring
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag