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

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 30 December 2008 23:15 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 464E628C305; Tue, 30 Dec 2008 15:15:13 -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 1709E28C304 for <saag@core3.amsl.com>; Tue, 30 Dec 2008 15:15:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.913
X-Spam-Level:
X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.686, 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 Jq2ShH7a-UDv for <saag@core3.amsl.com>; Tue, 30 Dec 2008 15:15:11 -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 EE47328C303 for <saag@ietf.org>; Tue, 30 Dec 2008 15:15:10 -0800 (PST)
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST)
Date: Tue, 30 Dec 2008 18:14:55 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Message-ID: <8A695EE544FEFDB0EDE3DD1A@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20081230223612.GN1872@Sun.COM>
References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <p0624081dc5802a331eac@[10.20.30.158]> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> <20081230223612.GN1872@Sun.COM>
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: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org
Subject: Re: [saag] [Cfrg] 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

--On Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> Applying a principle of redundancy in RTI algorithms to symmetric key
> protocols is fairly simple.  Applying such a principle to PKI seems
> rather more difficult -- it's not just hash algorithms, but pk
> algorithms too.  Your example was to require not just the implementation
> of multiple hash (but not pk) algorithms, but to require the *use* of
> those.  That makes sense to me, but it's not quite the same principle
> being applied to PKI as to SSH.

Correct.  I'm suggesting that in the case of PKI, merely having two RTI 
algorithms wouldn't be sufficient; at least for long-term certificates you 
need to actually sign using two algorithms in order to get the 
interoperability benefit.  Validating using both isn't necessary, though it 
does have a benefit, in that no code or configuration changes are required 
to continue to be safe as long as at least one is good enough.

IMHO, one of the biggest problems in the current PKI standards is that 
there is no ability to future-proof certificates by generating signatures 
with multiple algorithms.  The result is that you can't start signing with 
a new algorithm until everyone understands it, and you can't stop accepting 
an old algorithm without either reissuing lots of certificates with a new 
one or waiting for them to expire.  This means movement is very slow and we 
are unable to abandon a broken algorithm in a hurry.  The former is poor; 
the latter is a disaster waiting to happen.

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