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

Jeffrey Hutzelman <jhutz@cmu.edu> Sun, 04 January 2009 22:30 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 DCB983A689F; Sun, 4 Jan 2009 14:30:29 -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 287263A6A98 for <saag@core3.amsl.com>; Sun, 4 Jan 2009 14:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3uSo4dq+IhN8 for <saag@core3.amsl.com>; Sun, 4 Jan 2009 14:30:27 -0800 (PST)
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 2666D3A6885 for <saag@ietf.org>; Sun, 4 Jan 2009 14:30:27 -0800 (PST)
Received: from [172.16.209.63] (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n04MTvn9029995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 17:29:58 -0500 (EST)
Date: Sun, 04 Jan 2009 17:29:57 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <6C182FC59BEE26512261338E@atlantis.pc.cs.cmu.edu>
In-Reply-To: <200901042024.n04KOTfE014709@raisinbran.srv.cs.cmu.edu>
References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> <p06240804c586b9520715@[10.20.30.158]> <200901042024.n04KOTfE014709@raisinbran.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Cc: 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>
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 Sunday, January 04, 2009 10:23:58 PM +0200 Yoav Nir 
<ynir@checkpoint.com> wrote:

> On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:
>
>> At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>>> Best we can do is to get the CAs to
>>>
>>> (1) not issue MD5 certs anymore and
>>> (2) randomize the serial number and/or
>>> (3) and a random fluff extension that people are talking about
>>
>> Just to repeat it one more time: #3 does not prevent the published
>> attack.
>
> It does if the random fluff is inserted by the CA. The attack depends on
> their ability to predict the entire TBS part.

No, it does not.  It depends on their ability to predict that portion of 
the TBS part which occurs prior to the computed collision blocks, which in 
the real certificate occur in the subject public key modulus.  The portion 
of the TBS part which occurs after the collision blocks does not need to be 
predictable; they just need to be able to copy it as-is, which is done by 
copying the collision blocks, the rest of the original subject public key 
modulus, and all of the original certificate's extensions into a netscape 
comment extension in the forged certificate.

>>> And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/
>>> Chrome people don't want any sites that "only work with Explorer".
>>
>> At least with respect to Firefox, I think that statement is false.
>
> They've done quite a bit to render broken sites that were made for IE.
> Also, I've updated today and all the "bad" CAs with MD5 signatures are
> still in the TAS.

Again, there is nothing "bad" about CA certifiates with MD5 signatures. 
The signature on a root certificate is not used for anything, and in 
practice is not an accurate predictor of what algorithms that CA uses to 
sign certificates.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA

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