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

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 30 December 2008 22:53 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 4FCA428C2F6; Tue, 30 Dec 2008 14:53:17 -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 DF16628C2F6 for <saag@core3.amsl.com>; Tue, 30 Dec 2008 14:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.578
X-Spam-Level:
X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 rKfMKXUX61xm for <saag@core3.amsl.com>; Tue, 30 Dec 2008 14:53:16 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D63253A67F0 for <saag@ietf.org>; Tue, 30 Dec 2008 14:53:15 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUMr5gj000178 for <saag@ietf.org>; Tue, 30 Dec 2008 22:53:05 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mBUMr5o7041411 for <saag@ietf.org>; Tue, 30 Dec 2008 15:53:05 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 30 Dec 2008 16:36:12 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <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>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org

On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote:
> Incidentally, the recently reported problems with CBC mode ciphers in SSH 
> have gotten me to thinking that in some situations, a single REQUIRED 
> algorithm isn't enough, because if something goes wrong and you have to 
> abandon that algorithm in a hurry, operators may be in a position of having 
> to choose between seriously compromising either security or 
> interoperability.

+1

But note that in the case of the SSH CBC mode ciphers the vulnerable
ciphers had only the cipher mode in common.  The SSH vulnerability, in
any case, doesn't stem from the use of CBC, but is more general, and
well could have been worse, but let's ignore that for this argument.

So in the SSH case one would have liked to have seen two or more
REQUIRED to implement ciphers with very distinct properties.  Say
3DES in CBC mode, AES in counter mode, and arcfour.

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.

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