From saag-bounces@ietf.org Thu Jan 1 03:18:05 2009 Return-Path: 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 984A43A68BF; Thu, 1 Jan 2009 03:18:05 -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 B1B9C3A68BF for ; Thu, 1 Jan 2009 03:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, 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 yg+DEMju2zGx for ; Thu, 1 Jan 2009 03:18:04 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id E8C9B3A679C for ; Thu, 1 Jan 2009 03:18:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B9719481C06; Fri, 2 Jan 2009 00:17:51 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPAZbKuv7Db5; Fri, 2 Jan 2009 00:17:51 +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 048B4481BFB; Fri, 2 Jan 2009 00:17:51 +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 2436B1BE4002; Fri, 2 Jan 2009 00:17:50 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LILYj-00066V-WE; Fri, 02 Jan 2009 00:17:50 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, mike-list@pobox.com In-Reply-To: <495BA5E9.8040305@pobox.com> Message-Id: Date: Fri, 02 Jan 2009 00:17:49 +1300 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Mike writes: >> We are simply not vigilant enough. This issue has been on our plate >> since 2004. >> >> SHA-1 is next and neither the client side vendors nor the big >> Enterprises have pushed to move to SHA-256. > >There is a simple fix -- a CA can just reorder the extensions prior to >issuing a certificate. That's actually a nice fix, but unfortunately not universally applicable: for some types of signed data (e.g. S/MIME attributes) the DER rules require sorting the encoded extensions, so there's only one valid order for them (and some applications actually check for this, so you have to do it or sig checks will start failing). Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 03:40:07 2009 Return-Path: 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 092C33A68ED; Thu, 1 Jan 2009 03:40:07 -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 9605C3A68ED for ; Thu, 1 Jan 2009 03:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 0L5LB0XzXM54 for ; Thu, 1 Jan 2009 03:40:04 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 9F7863A679C for ; Thu, 1 Jan 2009 03:40:04 -0800 (PST) Received: (qmail 10279 invoked from network); 1 Jan 2009 11:40:15 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 01 Jan 2009 11:40:15 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 11:40:15 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jan 2009 06:39:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclsApjZvyr7mv5ST36mpmxAU3jJIwAAnlMA References: <495BA5E9.8040305@pobox.com> From: "Santosh Chokhani" To: "Peter Gutmann" , , Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Also, for the actual attack, the ordering of extensions will not work as long as the certificate size does not change. If you look at the actual attack, collision block in the real certificate is up to the SPKI. The extension values from the real certificate are simply copied in the tumor of the rogue certificate. Given the property that if H(M) = H (M') then H(M | X) = H (M' | X), the attacker simply copies the extensions from actual certificate in the tumor. -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Thursday, January 01, 2009 6:18 AM To: ietf-pkix@imc.org; mike-list@pobox.com Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Mike writes: >> We are simply not vigilant enough. This issue has been on our plate >> since 2004. >> >> SHA-1 is next and neither the client side vendors nor the big >> Enterprises have pushed to move to SHA-256. > >There is a simple fix -- a CA can just reorder the extensions prior to >issuing a certificate. That's actually a nice fix, but unfortunately not universally applicable: for some types of signed data (e.g. S/MIME attributes) the DER rules require sorting the encoded extensions, so there's only one valid order for them (and some applications actually check for this, so you have to do it or sig checks will start failing). Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 03:43:13 2009 Return-Path: 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 806CA3A6904; Thu, 1 Jan 2009 03:43: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 085D83A6904 for ; Thu, 1 Jan 2009 03:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.162 X-Spam-Level: X-Spam-Status: No, score=-4.162 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uFGncYY7kCHL for ; Thu, 1 Jan 2009 03:43:11 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 1A3103A679C for ; Thu, 1 Jan 2009 03:43:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 576539D817; Fri, 2 Jan 2009 00:11:23 +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 (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StmylvlTOtW7; Fri, 2 Jan 2009 00:11:23 +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 DE48F9D81F; Fri, 2 Jan 2009 00:11:07 +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 7EC871BE4002; Fri, 2 Jan 2009 00:11:01 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LILS9-0005ff-DN; Fri, 02 Jan 2009 00:11:01 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: SChokhani@cygnacom.com, tmiller@mitre.org In-Reply-To: Message-Id: Date: Fri, 02 Jan 2009 00:11:01 +1300 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 "Santosh Chokhani" writes: >We are simply not vigilant enough. This issue has been on our plate since >2004. It's not just this, the fact that there were CA certs out there with the CA flag (in basicConstraints) not set was known for at least five years before widespread bad publicity forced CAs to address it, the RSA exponent=1 debacle was known for at least that long but no-one cared until there was lots of bad publicity about it... there's a really serious problem with CAs and vendors simply not caring about PKI security until bad publicity forces a change, the curent MD5 issue (and the mozilla.com cert debacle and the Gromozon malware- signing cert issue and ...) are just the latest examples. It's like the Microsoft of ten years ago, security holes just get ignored until bad publicity forces a fix (and even then it's often more of a sidestep to avoid further criticism than an actual fix). It's small wonder that there's such widespread cynicism about PKI when even the organisations pushing it don't seem to care whether it's done properly or not. Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 07:37:49 2009 Return-Path: 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 44B643A6981; Thu, 1 Jan 2009 07:37:49 -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 789AE3A6981 for ; Thu, 1 Jan 2009 07:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 eseLMnVWbZBy for ; Thu, 1 Jan 2009 07:37:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C85393A67E9 for ; Thu, 1 Jan 2009 07:37:46 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n01F6Oow000976 for ; Thu, 1 Jan 2009 07:06:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1230822384; bh=tg074PHvAieD9nLWnxuDNpZtK/w=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=ld8Q1x 2Qe8nmZpqx28goLItJY5Rkmd4OUzgxG3cjxdlOw9RB9CL+4wA7YqIs2Lu1xPn90BMcD yG1XqZ2ETG/iA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding: x-gmailtapped-by:x-gmailtapped; b=SDP1VJVvxF7AdY8Sn2Sajro/oqwFNciLHzHZ5IjeUyksU/pyZNeVEluRi6i/GVk7S lFifwJheHTCjD2Etawdeg== Received: from fg-out-1718.google.com (fge13.prod.google.com [10.86.5.13]) by zps37.corp.google.com with ESMTP id n01F6ILr011266 for ; Thu, 1 Jan 2009 07:06:19 -0800 Received: by fg-out-1718.google.com with SMTP id 13so533295fge.41 for ; Thu, 01 Jan 2009 07:06:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.59.18 with SMTP id h18mr8480886fga.45.1230822377800; Thu, 01 Jan 2009 07:06:17 -0800 (PST) In-Reply-To: References: <495BA5E9.8040305@pobox.com> Date: Thu, 1 Jan 2009 15:06:17 +0000 Message-ID: <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> From: Ben Laurie To: Peter Gutmann X-GMailtapped-By: 172.25.146.37 X-GMailtapped: benl Cc: ietf-pkix@imc.org, mike-list@pobox.com, cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann wrote: > > Mike writes: > >There is a simple fix -- a CA can just reorder the extensions prior to > >issuing a certificate. > > That's actually a nice fix, but unfortunately not universally applicable: for > some types of signed data (e.g. S/MIME attributes) the DER rules require > sorting the encoded extensions, so there's only one valid order for them (and > some applications actually check for this, so you have to do it or sig checks > will start failing). Surely the whole point of DER is that there's only one correct way to encode any particular certificate? So, either extensions must be sorted, or changing their order changes their meaning. Either way, nothing can be reordered. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 08:51:00 2009 Return-Path: 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 368BC3A68B9; Thu, 1 Jan 2009 08:51:00 -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 EF25B3A68B9 for ; Thu, 1 Jan 2009 08:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] 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 wQIYBCpwYne3 for ; Thu, 1 Jan 2009 08:50:58 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 2362E3A65A5 for ; Thu, 1 Jan 2009 08:50:58 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5783750822; Thu, 1 Jan 2009 09:07:06 -0800 (PST) Date: Thu, 01 Jan 2009 09:07:05 -0800 From: Eric Rescorla To: Mike In-Reply-To: <495CE68A.5040709@pobox.com> References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495CE68A.5040709@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090101170706.5783750822@romeo.rtfm.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At Thu, 01 Jan 2009 07:51:38 -0800, Mike wrote: > > > Is there anything that could be added to RP software to reliably > detect and thwart the use of a rogue CA certificate? Or would > any attempt to do that just cause too many problems? > > Mike (who is writing "I am not a security expert" 100 times on > the chalkboard) You could certainly add a check for this particular certificate and any others you discovered. To the extent to which CAs no longer use MD5, this would likely quickly clean up the damage. It's less clear that you could safely detect this kind of cert in a generic way. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 09:01:46 2009 Return-Path: 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 231E828C155; Thu, 1 Jan 2009 09:01:46 -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 C2C9728C14F for ; Thu, 1 Jan 2009 09:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 MmJXAtZhlynm for ; Thu, 1 Jan 2009 09:01:45 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id D0F1A28C155 for ; Thu, 1 Jan 2009 09:01:44 -0800 (PST) Received: (qmail 11256 invoked from network); 1 Jan 2009 15:15:13 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 01 Jan 2009 15:15:13 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 15:15:13 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jan 2009 10:14:49 -0500 Message-ID: In-Reply-To: <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclsIoYaC7zrH+YEQlGlPwinB2nccwAAQV+A References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> From: "Santosh Chokhani" To: "Ben Laurie" , "Peter Gutmann" Cc: ietf-pkix@imc.org, mike-list@pobox.com, cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Changing the order of extensions does not change their meaning. Actually, a CA could put the extensions in random order for various certificates. The attack will still work if the certificate size does not change. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Ben Laurie Sent: Thursday, January 01, 2009 10:06 AM To: Peter Gutmann Cc: ietf-pkix@imc.org; mike-list@pobox.com; cfrg@irtf.org; saag@ietf.org; ietf-smime@imc.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann wrote: > > Mike writes: > >There is a simple fix -- a CA can just reorder the extensions prior to > >issuing a certificate. > > That's actually a nice fix, but unfortunately not universally applicable: for > some types of signed data (e.g. S/MIME attributes) the DER rules require > sorting the encoded extensions, so there's only one valid order for them (and > some applications actually check for this, so you have to do it or sig checks > will start failing). Surely the whole point of DER is that there's only one correct way to encode any particular certificate? So, either extensions must be sorted, or changing their order changes their meaning. Either way, nothing can be reordered. _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 09:20:26 2009 Return-Path: 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 B028528C164; Thu, 1 Jan 2009 09:20:26 -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 D4BE33A65A5; Thu, 1 Jan 2009 09:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 dNAge8yHkfL1; Thu, 1 Jan 2009 09:20:25 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D2A4A3A689C; Thu, 1 Jan 2009 09:20:24 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01HK1Rw084974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:20:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> Date: Thu, 1 Jan 2009 09:20:00 -0800 To: Ben Laurie , Peter Gutmann From: Paul Hoffman Cc: ietf-pkix@imc.org, mike-list@pobox.com, cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 3:06 PM +0000 1/1/09, Ben Laurie wrote: >Surely the whole point of DER is that there's only one correct way to >encode any particular certificate? Not so "surely". The SEQUENCE for extensions does not say what order they should be in. >So, either extensions must be sorted, or changing their order changes >their meaning. Either way, nothing can be reordered. Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order. However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 09:44:44 2009 Return-Path: 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 763DF3A6981; Thu, 1 Jan 2009 09:44: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 198D03A6981 for ; Thu, 1 Jan 2009 09:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 46bhh8I2Hlop for ; Thu, 1 Jan 2009 09:44:42 -0800 (PST) Received: from mail.links.org (mail.links.org [217.155.92.109]) by core3.amsl.com (Postfix) with ESMTP id 32C403A6974 for ; Thu, 1 Jan 2009 09:44:42 -0800 (PST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5BA8133C1E; Thu, 1 Jan 2009 17:46:01 +0000 (GMT) Message-ID: <495D0100.6000200@links.org> Date: Thu, 01 Jan 2009 17:44:32 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, mike-list@pobox.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Paul Hoffman wrote: > At 3:06 PM +0000 1/1/09, Ben Laurie wrote: >> Surely the whole point of DER is that there's only one correct way to >> encode any particular certificate? > > Not so "surely". The SEQUENCE for extensions does not say what order they should be in. That doesn't change the _point_ of DER. If extensions should have been specified as a SET but are defined as a SEQUENCE, then they are broken (technically). >> So, either extensions must be sorted, or changing their order changes >> their meaning. Either way, nothing can be reordered. > > Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order. My point was about the correct use of DER. It seems extensions use it incorrectly. > However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper. I am discussing the correct use of DER :-) -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 11:30:02 2009 Return-Path: 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 0B9A23A6AB9; Thu, 1 Jan 2009 11:30:02 -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 4E3C03A6AB9 for ; Thu, 1 Jan 2009 11:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Fu2fj0JQaHct for ; Thu, 1 Jan 2009 11:30:00 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 20FD13A6813 for ; Thu, 1 Jan 2009 11:29:59 -0800 (PST) Received: (qmail 12442 invoked from network); 1 Jan 2009 19:30:10 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 01 Jan 2009 19:30:10 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 19:30:10 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jan 2009 14:29:46 -0500 Message-ID: In-Reply-To: <495D0100.6000200@links.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclsOJwh2A/o+dm4RcK781oKyPwOkAADl7sA References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495D0100.6000200@links.org> From: "Santosh Chokhani" To: "Ben Laurie" , "Paul Hoffman" Cc: mike-list@pobox.com, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org We must fix X.509 since it is not broken. We must preserve MD5 since it is weak. We must provide economic and political support to client side vendors who refuse to implement SHA-256. We must treat them with kid gloves and work around them. The world economy is in the tank. People want to shoot each other. I see a patent here that is not very random. -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Thursday, January 01, 2009 12:45 PM To: Paul Hoffman Cc: cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org; mike-list@pobox.com Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Paul Hoffman wrote: > At 3:06 PM +0000 1/1/09, Ben Laurie wrote: >> Surely the whole point of DER is that there's only one correct way to >> encode any particular certificate? > > Not so "surely". The SEQUENCE for extensions does not say what order they should be in. That doesn't change the _point_ of DER. If extensions should have been specified as a SET but are defined as a SEQUENCE, then they are broken (technically). >> So, either extensions must be sorted, or changing their order changes >> their meaning. Either way, nothing can be reordered. > > Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order. My point was about the correct use of DER. It seems extensions use it incorrectly. > However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper. I am discussing the correct use of DER :-) -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 11:40:06 2009 Return-Path: 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 802CF28C171; Thu, 1 Jan 2009 11:40:06 -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 097CE28C171 for ; Thu, 1 Jan 2009 11:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 XI-+21LCkLyU for ; Thu, 1 Jan 2009 11:40:04 -0800 (PST) Received: from mail.links.org (mail.links.org [217.155.92.109]) by core3.amsl.com (Postfix) with ESMTP id 25DFF28C169 for ; Thu, 1 Jan 2009 11:40:04 -0800 (PST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6A66333C1E; Thu, 1 Jan 2009 19:41:23 +0000 (GMT) Message-ID: <495D1C0A.2080105@links.org> Date: Thu, 01 Jan 2009 19:39:54 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Santosh Chokhani References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495D0100.6000200@links.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, mike-list@pobox.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Santosh Chokhani wrote: > We must fix X.509 since it is not broken. I am not suggesting that we should fix X.509, I am pointing out, in my own roundabout way, that X.509 certs are supposed to have a canonical form. But it seems they do not. Makes me wonder why we go to all the effort of using a supposedly canonical encoding that isn't? If we can only rely on the original bits in the cert when checking the signature, why bother? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 1 11:48:55 2009 Return-Path: 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 C75C828C16C; Thu, 1 Jan 2009 11:48:55 -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 1668628C16C for ; Thu, 1 Jan 2009 11:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 tYxSsRYBDQ+v for ; Thu, 1 Jan 2009 11:48:53 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id E927028C169 for ; Thu, 1 Jan 2009 11:48:52 -0800 (PST) Received: (qmail 12536 invoked from network); 1 Jan 2009 19:49:03 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 01 Jan 2009 19:49:03 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 19:49:03 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jan 2009 14:48:40 -0500 Message-ID: In-Reply-To: <495D1C0A.2080105@links.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclsSLgggyxnPlLcRtiDUadx0CecswAANOjQ References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495D0100.6000200@links.org> <495D1C0A.2080105@links.org> From: "Santosh Chokhani" To: "Ben Laurie" Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, mike-list@pobox.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org I do not think canonical means only one way to represent. Extensions have always been a SEQUENCE with their OID denoting what extension is next and their syntax. Actually, we find SET in the case of RDN problematic. -----Original Message----- From: Ben Laurie [mailto:ben@links.org] Sent: Thursday, January 01, 2009 2:40 PM To: Santosh Chokhani Cc: Paul Hoffman; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org; mike-list@pobox.com Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > We must fix X.509 since it is not broken. I am not suggesting that we should fix X.509, I am pointing out, in my own roundabout way, that X.509 certs are supposed to have a canonical form. But it seems they do not. Makes me wonder why we go to all the effort of using a supposedly canonical encoding that isn't? If we can only rely on the original bits in the cert when checking the signature, why bother? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Jan 2 07:36:43 2009 Return-Path: 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 1A67D3A69A4; Fri, 2 Jan 2009 07:36:43 -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 B65E13A69A4 for ; Fri, 2 Jan 2009 07:36:41 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "References" occurs 6 times X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 diZ4k8Tf+j6t for ; Fri, 2 Jan 2009 07:36:41 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id C9BA53A6849 for ; Fri, 2 Jan 2009 07:36:39 -0800 (PST) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n02FZsW3016664; Fri, 2 Jan 2009 10:35:54 -0500 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Fri, 02 Jan 2009 10:35:43 -0500 (EST) Date: Fri, 2 Jan 2009 10:35:34 -0500 From: Robert Moskowitz To: Peter Hesse Message-ID: <495E3446.4070606@htt-consult.com> In-Reply-To: <0c6f01c96ce8$2c13d700$843b8500$@com> References: <495BA5E9.8040305@pobox.com> References: References: <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> References: References: <495CE68A.5040709@pobox.com> References: <0c6f01c96ce8$2c13d700$843b8500$@com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 Content-Disposition: inline Cc: ietf-pkix@imc.org, 'Mike' , cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Peter Hesse wrote: >> Is there anything that could be added to RP software to reliably >> detect and thwart the use of a rogue CA certificate? Or would >> any attempt to do that just cause too many problems? >> > > Since MD5 is known bad and potentially dangerous at this point, I would > suggest that the best client side action would be to fail to verify any > signatures created using MD5. This will break some things, especially if > existing business processes are relying on a certificate signed with MD5. > However, it is a fail-safe and would prevent a rogue CA certificate created > in this fashion from being considered trustworthy. > > And to Santosh's point (and others), my earlier email about > removing/replacing trust anchors was not because the self-signed > certificates are signed using MD5; I agree the trust anchor public keys are > protected using other mechanisms. I am recommending that if CAs do nothing > to prevent this kind of attack (non-random serial numbers, issue > certificates signed with MD5, issue certificates in an automated, > predictable fashion) that those CAs should be removed from trust lists > because they are no longer acting in the interest of the relying party--they > are an accomplice to the creation of these rogue certificates. Peter, This sounds great at an IETF mike, but out in the field how do you get all those millions of browsers to pull down a new trust list that will no longer include CA foobar? Can't happen now, and the way things are going, ain't going to happen before 2026 either. So what tool do we have to get compliance to best practices? The good old 5th estate, get out their and give bad press to foobar until they fix their behaviour or their business model collapses and they go out of business and can no longer issue potentially rogue certs. We can talk and posture all we want in the IETF. We are rather good at that, IMNSHO. But this is perfect proof of our impact as such on the business model of companies that use our technology; they will do what is expedient, not what is Best Practices. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sat Jan 3 22:57:17 2009 Return-Path: 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 448693A68BB; Sat, 3 Jan 2009 22:57: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 387593A69CD for ; Sat, 3 Jan 2009 22:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599] 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 6Js2tp6caRjq for ; Sat, 3 Jan 2009 22:57:14 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 229E43A63EB for ; Sat, 3 Jan 2009 22:57:14 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KCX008WXPYZ15@szxga01-in.huawei.com> for saag@ietf.org; Sun, 04 Jan 2009 14:56:59 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KCX00BRDPYZOO@szxga01-in.huawei.com> for saag@ietf.org; Sun, 04 Jan 2009 14:56:59 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KCX0036MPYVAH@szxml05-in.huawei.com> for saag@ietf.org; Sun, 04 Jan 2009 14:56:59 +0800 (CST) Date: Sun, 04 Jan 2009 14:56:55 +0800 From: Sean Shen In-reply-to: To: saag@ietf.org Message-id: <000101c96e39$a1b36690$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AclrgQN5ksL11e1iQy2M+lQmJsX4VQCtdEfA Cc: cfrg@irtf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi, I agree with the value of some document providing analysis of crypto threats on IETF protocols, RFC4270 (Attacks on Cryptographic Hashes in Internet Protocols ) did a good job on this. I think more analysis for different IETF protocols can be provides and this type of information document can be updated periodically (at least when there is big cryptoanalysis improvement). Thanks, Sean >-----Original Message----- >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >Behalf Of RJ Atkinson >Sent: Thursday, January 01, 2009 3:50 AM >To: saag@ietf.org >Cc: cfrg@irtf.org >Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a >rogue CAcertificate > > >On 31 Dec 2008, at 14:14, Rich Graveman wrote: >> For an expert, authoritative, and incredibly up-to-date tutorial on >> the state of hash functions, go to http://www.inscrypt.cn/, get the >> invited talks, and see the one by Preneel. If the intro material is >> boring, flip to slide 45 and start reading. No, MD5 and >SHA-1 are not >> quite in the same boat. > >Those talk about the hash functions generally, but they do not >really address the question specifically *as such functions >are actually employed by some number of IETF protocols*. (And >just to be clear, I'm thinking quite broadly -- well beyond >the narrow realm of hashes as used by certificates.) > >A collision attack on some hash function f() might or might >not be an issue if f() is used in any of several different >modes, for example. > >> Unfortunately, the ways cryptologists look at these things and the >> ways the IETF uses them are not always the same, so there is >more work >> to do. > >Right. What I was asking for, specifically, was analysis that >considered the various ways that various IETF protocols >actually use them -- not abstract concerns that might or might >not relate to the way they are actually used by various IETF protocols. >("ways" means not just deployment model, but also the mode of >operation). > >One could easily imagine, for example, that some uses of these >algorithms might be viewed as entirely fine, with other uses >being clearly unsuitable, with a wide range of possibilities >in between those two extremes. > >It is this specific analysis that is missing, needed, and >would be most valuable to various IETF WGs -- if available in >a public document (ideally an Informational RFC, developed >jointly as a public group effort, such as by the IRTF CFRG, >and including full references to the public literature). > >My apologies for somehow being unclear in my earlier note. > >Thanks, > >Ran >rja@extremenetworks.com > > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sat Jan 3 23:30:01 2009 Return-Path: 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 BA95A3A68F8; Sat, 3 Jan 2009 23:30:01 -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 2B7793A68F8 for ; Sat, 3 Jan 2009 23:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 zdWMASaUURTV for ; Sat, 3 Jan 2009 23:30:00 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E6B943A68DD for ; Sat, 3 Jan 2009 23:29:59 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4FBC5200DFE; Sun, 4 Jan 2009 09:29:43 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9F8852004D6; Sun, 4 Jan 2009 09:29:18 +0200 (IST) X-CheckPoint: {49606375-10000-88241DC2-7B6} Received: from owoloch-x32.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n047TIfE017615; Sun, 4 Jan 2009 09:29:18 +0200 (IST) Message-Id: <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> From: Yoav Nir To: Robert Moskowitz In-Reply-To: <495E3446.4070606@htt-consult.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 4 Jan 2009 09:02:00 +0200 References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> X-Mailer: Apple Mail (2.930.3) Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, Peter Hesse , 'Mike' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Jan 2, 2009, at 5:35 PM, Robert Moskowitz wrote: >> Since MD5 is known bad and potentially dangerous at this point, I >> would >> suggest that the best client side action would be to fail to verify >> any >> signatures created using MD5. This will break some things, >> especially if >> existing business processes are relying on a certificate signed >> with MD5. >> However, it is a fail-safe and would prevent a rogue CA certificate >> created >> in this fashion from being considered trustworthy. >> >> And to Santosh's point (and others), my earlier email about >> removing/replacing trust anchors was not because the self-signed >> certificates are signed using MD5; I agree the trust anchor public >> keys are >> protected using other mechanisms. I am recommending that if CAs do >> nothing >> to prevent this kind of attack (non-random serial numbers, issue >> certificates signed with MD5, issue certificates in an automated, >> predictable fashion) that those CAs should be removed from trust >> lists >> because they are no longer acting in the interest of the relying >> party--they >> are an accomplice to the creation of these rogue certificates. > Peter, > > This sounds great at an IETF mike, but out in the field how do you > get all those millions of browsers to pull down a new trust list > that will no longer include CA foobar? > > Can't happen now, and the way things are going, ain't going to > happen before 2026 either. There's this one company such that if they use Windows update to update their browsers, the others will follow. Technically, it's very easy to get rid of the bad CAs. However, that company is not going to modify their browsers, not now, probably not in the next few years. > So what tool do we have to get compliance to best practices? The > good old 5th estate, get out their and give bad press to foobar > until they fix their behaviour or their business model collapses and > they go out of business and can no longer issue potentially rogue > certs. I don't think you can get a message like that across. This story evokes more of the "Wow! Clever hackers with 200 playstations" sentiment, not the "criminal negligence" sentiment. You can't get the media angry with a company unless the negligence causes something spectacular, like an exploding Ford Pinto. Even Jesse Walker's "unsafe at any keylength" article didn't have quite the impact of the original. And people still use WEP. > We can talk and posture all we want in the IETF. We are rather good > at that, IMNSHO. But this is perfect proof of our impact as such on > the business model of companies that use our technology; they will > do what is expedient, not what is Best Practices. 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 But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates. And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/ Chrome people don't want any sites that "only work with Explorer". Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 11:11:33 2009 Return-Path: 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 1B8A63A6974; Sun, 4 Jan 2009 11:11:33 -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 369AA3A6934; Sun, 4 Jan 2009 11:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 tugWycIrZqQm; Sun, 4 Jan 2009 11:11:30 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 23EAD3A689C; Sun, 4 Jan 2009 11:11:29 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04JBA90047521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 12:11:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> Date: Sun, 4 Jan 2009 11:11:09 -0800 To: Yoav Nir From: Paul Hoffman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org 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. >But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates. It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know. >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. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 12:24:40 2009 Return-Path: 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 F03F33A689C; Sun, 4 Jan 2009 12:24:39 -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 1C3E53A68EF for ; Sun, 4 Jan 2009 12:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 qV+Q5zCiDeCq for ; Sun, 4 Jan 2009 12:24:38 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 361D53A6813 for ; Sun, 4 Jan 2009 12:24:38 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 163CA29C002; Sun, 4 Jan 2009 22:24:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3510F29C001; Sun, 4 Jan 2009 22:24:03 +0200 (IST) X-CheckPoint: {49611904-10000-88241DC2-7B6} Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n04KNwfE013740; Sun, 4 Jan 2009 22:23:59 +0200 (IST) Message-Id: From: Yoav Nir To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 4 Jan 2009 22:23:58 +0200 References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> X-Mailer: Apple Mail (2.930.3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org 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. >> But still, I don't see Microsoft removing a root CA because one of >> their sub-CAs is issuing non-compliant certificates. > > It is hard to see Microsoft removing or adding CAs. If anyone knows > of a public interface (mailing list, web site, whatever) for when > this happens, by all means please the world know. I managed to find a page with their policy on adding new root CAs. Nothing there about removing old root CAs. >> 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. Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 12:40:33 2009 Return-Path: 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 3283C28C0E8; Sun, 4 Jan 2009 12:40:33 -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 44C9E28C0DB; Sun, 4 Jan 2009 12:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 JWEdNJOu5Lpn; Sun, 4 Jan 2009 12:40:30 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 08C2D28C0CE; Sun, 4 Jan 2009 12:40:29 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04KeBuF050753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 13:40:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> Date: Sun, 4 Jan 2009 12:40:10 -0800 To: Yoav Nir From: Paul Hoffman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 10:23 PM +0200 1/4/09, Yoav Nir 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. I may have misunderstood the paper, but I think that changes after the subjectPublicKeyInfo do not affect the attack. >>>But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates. >> >>It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know. > >I managed to find a page with their policy on adding new root CAs. Nothing there about removing old root CAs. I'm not talking about the policy: I'm talking about the actual trust anchors themselves. >>>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. That is irrelevant for this thread. There are active discussions in the Firefox community about adding and removing trust anchors that are and are not already in the IE trust anchor pile. >Also, I've updated today and all the "bad" CAs with MD5 signatures are still in the TAS. As was pointed out to me earlier: it does not matter if the CA has its cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL, for example, is still signed with MD5 but is now signing with SHA-1. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 14:30:29 2009 Return-Path: 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 ; 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 ; 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 ; 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 To: Yoav Nir , Paul Hoffman 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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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) Carnegie Mellon University - Pittsburgh, PA _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 14:34:38 2009 Return-Path: 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 677C43A6AB7; Sun, 4 Jan 2009 14:34:38 -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 A34FA3A6AB7 for ; Sun, 4 Jan 2009 14:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 7J7ShheQLO9q for ; Sun, 4 Jan 2009 14:34:36 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 86AC93A6885 for ; Sun, 4 Jan 2009 14:34:36 -0800 (PST) Received: (qmail 6928 invoked from network); 4 Jan 2009 22:34:40 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 04 Jan 2009 22:34:40 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Jan 2009 22:34:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 4 Jan 2009 17:34:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclurKoRqf7W7I+NT92pGLSCmb5SbAAD7uUg References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com><230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> From: "Santosh Chokhani" To: "Paul Hoffman" , "Yoav Nir" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org I agree with Paul. Unless the Length of TBD certificate as part of DER is made unpredictable, any values on extensions just go in the tumor. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Sunday, January 04, 2009 3:40 PM To: Yoav Nir Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate At 10:23 PM +0200 1/4/09, Yoav Nir 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. I may have misunderstood the paper, but I think that changes after the subjectPublicKeyInfo do not affect the attack. >>>But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates. >> >>It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know. > >I managed to find a page with their policy on adding new root CAs. Nothing there about removing old root CAs. I'm not talking about the policy: I'm talking about the actual trust anchors themselves. >>>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. That is irrelevant for this thread. There are active discussions in the Firefox community about adding and removing trust anchors that are and are not already in the IE trust anchor pile. >Also, I've updated today and all the "bad" CAs with MD5 signatures are still in the TAS. As was pointed out to me earlier: it does not matter if the CA has its cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL, for example, is still signed with MD5 but is now signing with SHA-1. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:24 2009 Return-Path: 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 64D673A6A97; Sun, 4 Jan 2009 22:54:24 -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 928463A69A0 for ; Tue, 30 Dec 2008 13:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.942, 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 hGV-9fDERKts for ; Tue, 30 Dec 2008 13:18:35 -0800 (PST) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by core3.amsl.com (Postfix) with ESMTP id D81B83A680D for ; Tue, 30 Dec 2008 13:18:35 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIO3h014517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2008 13:18:24 -0800 X-Auth-Received: from D-140-142-21-194.dhcp4.washington.edu (D-140-142-21-194.dhcp4.washington.edu [140.142.21.194]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIOpq023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Dec 2008 13:18:24 -0800 Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Paul Hoffman In-Reply-To: Message-ID: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2008.12.30.210424 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:24 2009 Return-Path: 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 A53803A6AC1; Sun, 4 Jan 2009 22:54:24 -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 2EF6128C1F1 for ; Tue, 30 Dec 2008 13:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ADEJDCkXw2gi for ; Tue, 30 Dec 2008 13:40:00 -0800 (PST) Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by core3.amsl.com (Postfix) with ESMTP id 188A128C0D9 for ; Tue, 30 Dec 2008 13:40:00 -0800 (PST) Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id 14CD01ECC7; Tue, 30 Dec 2008 21:39:34 +0000 (GMT) From: "Peter Hesse" To: "'RL 'Bob' Morgan'" , "'Paul Hoffman'" References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: Date: Tue, 30 Dec 2008 16:39:34 -0500 Message-ID: <08bb01c96ac7$1cd5a750$5680f5f0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtA Content-Language: en-us X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:24 2009 Return-Path: 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 E0E193A6ACD; Sun, 4 Jan 2009 22:54:24 -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 6753F28C2E6 for ; Tue, 30 Dec 2008 14:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 B1hC1f9yrgqD for ; Tue, 30 Dec 2008 14:23:53 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 9DACC28C271 for ; Tue, 30 Dec 2008 14:23:53 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4874565rvf.49 for ; Tue, 30 Dec 2008 14:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SOjf1T9xI3MBJb+v+mg2/Dsw2wPmsmYSixQ9iXiIRcA=; b=jLU/hS5jNIbna5Zku6U+axs1KV2KLYrQTa+hHCR/6kqe207G+tXYDsVPGgTJk0qupA RJNQu5TWWaiQBDzj6O/tCx4phcCEZunboOs+VpniRcdvoADq3XwUZ1mzr83/ud5RY47H 8qdO/4Hzhx0900vj2XpDMmQJIaimvjR/nKQhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fNUP7Tab+VzvZPlIZjRGwRfpijhSl5e12WjdlWGoMMTJAQLgGCUXaBh6fPtA/Uex4x SNJMbQy/susUqr3OwRpb03aw46n6l9v8rUN4Gu8YA/jVRFYUFah7cKKcTeg4ApodNWJq EylztJzNVq1Niy3z4I7ag/Xk1/BlZfI+34MHY= Received: by 10.140.226.14 with SMTP id y14mr7464473rvg.59.1230675822107; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Received: by 10.141.169.13 with HTTP; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Message-ID: <985966520812301423g7f9b5b33o9219f27216b17d18@mail.gmail.com> Date: Tue, 30 Dec 2008 14:23:42 -0800 From: "Blake Ramsdell" To: "Timothy J. Miller" In-Reply-To: <495A9B44.1010201@mitre.org> MIME-Version: 1.0 Content-Disposition: inline References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> 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] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 2:05 PM, Timothy J. Miller wrote: > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. It seems that the disruption caused by modifying serial number generation for existing CAs is pretty high. Would an easier solution be to either a) make the validity period vary slightly (in the documented attack, the notBefore was always a fixed interval from the submission time, and making this vary in a period of just a few minutes would have thwarted it, if I'm understanding correctly), or b) the CA sticks some random junk in the subject DN (not an MPEG of a cat, but maybe OU=sf9fj3 [some base64 PRNG data]). Blake -- Blake Ramsdell | http://www.blakeramsdell.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:25 2009 Return-Path: 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 31A0C28B56A; Sun, 4 Jan 2009 22:54:25 -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 C328E3A6835 for ; Tue, 30 Dec 2008 14:31:31 -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 nphNvrPMje2x for ; Tue, 30 Dec 2008 14:31:31 -0800 (PST) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id CE2803A67F0 for ; Tue, 30 Dec 2008 14:31:30 -0800 (PST) Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mBULqtr9007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:30:44 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-65-96-146-181.hsd1.nh.comcast.net [65.96.146.181] by newdasher.Dartmouth.EDU (Mac) via SMTP for id <138927721>; 30 Dec 2008 17:30:43 -0500 Message-ID: <495AA0F6.7060604@Dartmouth.edu> Date: Tue, 30 Dec 2008 17:30:14 -0500 From: Scott Rea User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302217.mBUMH7XD040595@balder-227.proper.com> In-Reply-To: <200812302217.mBUMH7XD040595@balder-227.proper.com> X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub2 (score=1.651, required 1, BAYES_00 -2.60, BLITZ_DISCLAIMER 0.05, HELO_DYNAMIC_IPADDR 4.20) X-MailScanner-SpamScore: s X-MailScanner-From: scott.rea@dartmouth.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Russ Housley wrote: > > >>> Regardless of that, the authors of the MD5 paper are correct: trust >>> anchors signed with MD5 are highly questionable as of today (well, >>> actually, since they published their last paper). Hopefully, the >>> maintainers of the popular trust anchor repositories (Microsoft, >>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>> MD2!) as soon as possible. >> >> This is a different claim than "CAs should stop issuing certs with >> MD5 signatures", which is what I as an amateur take away from a quick >> scan of the material. Obviously MD5 is suspect in various ways, but >> does this new work lead to the conclusion that MD5-signed roots are >> untrustworthy today? > > We recommended a migration (walk, don't run) away from MD2, MD4, and > SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit > hash values; even without the attacks, these are getting to be too > small. SHA-1 has been shown to be weaker than its design goal, and > the 160 bit hash value will be getting too short in a couple of > years. We recommended SHA-256 while fully recognizing that NIST was > starting a hash competition, and that we might recommend the winner of > that competition as the successor to SHA-256. > > I still strongly encourage the migration to SHA-256. > > The use of the random bits in the serial number are insurance against > similar problems being found in other hash functions. This insurance > will hopefully provide time to migrate to another hash function when > cryptanalysis begins to show flaws in any future hash function. > > Russ But one of the things that has kept the brakes on migration has been support in clients for SHA256 - the largest vendor of client machines only just recently added SHA256 to its XP platform (if you upgrade to SP3). I keep running into folks using OpenSSL as their crypto base and they haven't updated to a distribution that supports SHA256. I think it will take a little more time before it becomes the default... -- Scott Rea _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:25 2009 Return-Path: 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 75B6428C0E0; Sun, 4 Jan 2009 22:54:25 -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 73A7528C300 for ; Tue, 30 Dec 2008 14:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 sjyIfwwZmdRG for ; Tue, 30 Dec 2008 14:55:01 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 619AA28C2F6 for ; Tue, 30 Dec 2008 14:55:01 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6OPZ025827 for ; Tue, 30 Dec 2008 17:06:24 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6Ocb025814; Tue, 30 Dec 2008 17:06:24 -0500 Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 30 Dec 2008 17:06:24 -0500 Message-ID: <495A9B44.1010201@mitre.org> Date: Tue, 30 Dec 2008 16:05:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Eric Rescorla References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 CA certificate X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608015119==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0608015119== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706050700070408070900" --------------ms000706050700070408070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > I don't know whether many or most do it. IMO everyone should. Randomizing serial numbers has implications for OCSP operations, particularly those that use presigned responses in order to optimize performance. Why presign? Because for a large network with varying levels of support, it may be easier to move around sets of pre-produced responses to distributed keyless OCSP responders than to guarantee connectivity to a keyed OCSP service. Why presign batches rather than individual responses? Because for a large PKI the response pre-production time can exceed the CRL update frequency. -- Tim --------------ms000706050700070408070900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzAyMjA1NTZaMCMGCSqGSIb3DQEJBDEWBBQ4RbejFRP0hZy6Vjhh795xqhnGfDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgELzHlPR7X3MOFLP5ZcY1mbMXJyVuu8D6m/7NK0eZrsmu7YMbLzv7t5txCiQ 6CHlVuWg0WcLwT24dUazLur+cNII/+p5MiS42K0qScSEoWc7uJDgKtmol40n1brGU7mVvLVm oNAh3ZUvQV/gAJ3VbnN61DL/Eld+TlsdEjGJ8SirAAAAAAAA --------------ms000706050700070408070900-- --===============0608015119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0608015119==-- From saag-bounces@ietf.org Sun Jan 4 22:54:25 2009 Return-Path: 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 B918A28C0E8; Sun, 4 Jan 2009 22:54:25 -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 F01A93A69AC for ; Wed, 31 Dec 2008 06:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 VCSblIdr22Rd for ; Wed, 31 Dec 2008 06:43:38 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 63A463A6850 for ; Wed, 31 Dec 2008 06:43:35 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhO1Y005883 for ; Wed, 31 Dec 2008 09:43:24 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhOWH005873; Wed, 31 Dec 2008 09:43:24 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 09:43:24 -0500 Message-ID: <495B84F0.3030506@mitre.org> Date: Wed, 31 Dec 2008 08:42:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> In-Reply-To: <200812302223.mBUMNqDL040943@balder-227.proper.com> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0337014208==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0337014208== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080405090908050504" --------------ms090606080405090908050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ Housley wrote: > >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. > > That works. This works too: the serial number could be composed of > two parts, where the most significant bits are a counter and the > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim --------------ms090606080405090908050504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNDQyNTZaMCMGCSqGSIb3DQEJBDEWBBTfbxF7sn3oqEN3WXpHFQsd8theZDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgBZT/e02nOU5oLHw8SlL6T03B11F/xNZ0nz2O8tH5cZlJO9MLivLWFMt7kuj +OfGq/Rbd1s8iuLaOutkrqN86npxL/gDNTA9HhiOUS7uN6rWywF/2tptx4S0l7lJRMDg/BcX 0kefE1Ivxq3RU/taMplV1KFiHkJ7LJUnlyHecbu2AAAAAAAA --------------ms090606080405090908050504-- --===============0337014208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0337014208==-- From saag-bounces@ietf.org Sun Jan 4 22:54:26 2009 Return-Path: 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 0E21828C0EE; Sun, 4 Jan 2009 22:54:26 -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 122793A69C5 for ; Wed, 31 Dec 2008 07:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 Iya2CTbpYwxx for ; Wed, 31 Dec 2008 07:18:44 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 669C33A67FF for ; Wed, 31 Dec 2008 07:18:44 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXwP002392 for ; Wed, 31 Dec 2008 10:18:33 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXZb002386; Wed, 31 Dec 2008 10:18:33 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 10:18:33 -0500 Message-ID: <495B8D28.6070601@mitre.org> Date: Wed, 31 Dec 2008 09:18:00 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> In-Reply-To: X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1791157984==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1791157984== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306030909090007020003" --------------ms050306030909090007020003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser forum guidelines for EV certs allows (but recommends against) MD5 until 2010. The spot check of EV issuers I did yesterday didn't turn up anyone actually using MD5, but I didn't have all of 'em available. -- Tim --------------ms050306030909090007020003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNTE4MDBaMCMGCSqGSIb3DQEJBDEWBBTYJibxLOyG1SEmTVXB/AhI0/Bt8jBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgAZCH6+J56WxRyI0sA7T1gbC1tsCwYnjNsqIpESy0TwpwrdIYDgtwOARQOev InbqiDYQerQmWIIH+ovlzYIUazy21FVc8ReHKFTXOrx4GLrDvGSwGfsDrc8Rz8l5dcP0rXUS J6/YQsvvbM90MY/o0TBIWI2i8PG5c5mVmkkYr+E9AAAAAAAA --------------ms050306030909090007020003-- --===============1791157984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1791157984==-- From saag-bounces@ietf.org Sun Jan 4 22:54:26 2009 Return-Path: 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 56B5428C0F6; Sun, 4 Jan 2009 22:54:26 -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 E28243A67FF for ; Wed, 31 Dec 2008 07:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IMIr6e20DHNE for ; Wed, 31 Dec 2008 07:37:12 -0800 (PST) Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by core3.amsl.com (Postfix) with SMTP id 11B483A687F for ; Wed, 31 Dec 2008 07:37:11 -0800 (PST) Received: (qmail 28690 invoked from network); 31 Dec 2008 15:36:57 -0000 Received: from tim.moses@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0; 31 Dec 2008 15:36:57 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 31 Dec 2008 15:36:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 10:36:56 -0500 Message-ID: <04398A2C9F306C4690265C144089972D0D3B3B13@sottexch1.corp.ad.entrust.com> In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrXBEEqsU/Y6e/ROuPhuoyz8ZfcAAAQNmw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Tim Moses" To: "Timothy J. Miller" X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2075001077==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============2075001077== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="--=_NextPart_EE_103656811.38200976" ----=_NextPart_EE_103656811.38200976 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Colleagues - It has been confirmed that no EV issuer is signing certific= ates with MD5. Also, EV certificates cannot be issued by an automated p= rocess, putting another obstacle in the path of an attacker. All the be= st. Tim. Tim Moses +1 613 270 3183 -----Original Message----- From: owner-ietf-smime=40mail.imc.org =5Bmailto:owner-ietf-smime=40mail.= imc.org=5D On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix=40imc.org; ietf-smime=40imc.org; cfrg=40irtf.org; saag=40i= etf.org Subject: Re: =5BCfrg=5D =5Bsaag=5D Further MD5 breaks: Creating a rogue C= Acertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming=20 > client vendors implement SHA256 ASAP) and ask the CAs emanating from=20 > commercial roots to perform responsible I&A before issuing certificate= s. Speaking of I&A, I found it interesting to note that the CA/Browser foru= m guidelines for EV certs allows (but recommends against) MD5 until 2010= =2E The spot check of EV issuers I did yesterday didn't turn up anyone actua= lly using MD5, but I didn't have all of 'em available. -- Tim ----=_NextPart_EE_103656811.38200976 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCIIIwggKf MIICCKADAgECAgRGJ7vgMA0GCSqGSIb3DQEBBQUAMCwxCzAJBgNVBAYTAkNBMR0wGwYDVQQK ExRFbnRydXN0IFRlY2hub2xvZ2llczAeFw0wODA1MDcxMzA4MzlaFw0xMTA1MDcxMzM4Mzla MDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczCB nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptmAbxopaoSELaZIvJHlWg+vqcq kQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/3qwFvxG1Xkbi1UDo6qB/ TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7Zl4kdWkCAQOjgckw gcYwHQYDVR0OBBYEFAUkiCBOsLJRzMuh2elnJIbV+bBFME4GA1UdHwRHMEUwQ6BBoD+kPTA7 MQswCQYDVQQGEwJDQTEdMBsGA1UEChMURW50cnVzdCBUZWNobm9sb2dpZXMxDTALBgNVBAMT BENSTDEwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFDGPKjFGWl7oabci0fgBq6xQXgF1MAwG A1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCAIEwDQYJKoZIhvcNAQEFBQAD gYEAbdDF5a/A+vjthvR7ofXzM3UxI/62yW9yJPzQ7sN1AS9zKgPB9Nm4tySDwSeFvqQ1/KOv JTEeYABGRaZ1YrTXc2mFhTlcLQAZ16DsS2VxnKqhEVWq4JaUaJAe9qvKvdkvpDieKQMkfM0c WZCa9b396rZKqSd+j86yP6FauYSrw6wwggLfMIICSKADAgECAgRGS07GMA0GCSqGSIb3DQEB BQUAMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQcm9kMB4X DTA3MDUyMjE0NTQ0N1oXDTEwMDUyMjE1MjQ0N1owLDELMAkGA1UEBhMCQ0ExHTAbBgNVBAoT FEVudHJ1c3QgVGVjaG5vbG9naWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5SPAE WITHCc04wRiDaJpJY8ZF7bCJ1ohhSyKRA2ouJ+sjRMqzfxXcxQTKuE4GQg1dvZjvmmZJq5KZ 71yZnvK+Kb1ixXP1y/zAy6CiiatTPrf8SNzXpSDon3VdKo8zuKQ6ELKaWP3nK4O4eOiXdmfn a2bOLzFi7TpKICfieMOdlQIDAQABo4IBCjCCAQYwHQYDVR0OBBYEFDGPKjFGWl7oabci0fgB q6xQXgF1MIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9MQswCQYDVQQGEwJjYTEQMA4GA1UEChMH ZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UEAxMEQ1JMMTA5oDegNYYzZmlsZTovL1xc U09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2NhX2NybGZpbGUuY3JsMAsGA1UdDwQEAwIB BjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAMBgNVHRMEBTADAQH/MBkGCSqG SIb2fQdBAAQMMAobBFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAEnSrabNwGiiZNjhIFce 7VctEE5uR6RaADbc6hszcn50pYoliCY5T53dUpOvznUuDX0HWFfH+YXl3Isol2p0DbSSAFNv 8OWyEAd2SoYRinBNpMOyQlrTWt5FBiCB2dglbxx/I2eyTqr5COy8u/ijLKvVn00yBf3f1kCw d+//jQluMIIC7TCCAlagAwIBAgIEMkbEozANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNOTgwODE5MTkxMjA2 WhcNMTgwODE5MTk0MjA2WjAyMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8G A1UECxMIQnVzaW5lc3MwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBANCAYKBlpcKbZgG8 aKWqEhC2mSLyR5VoPr6nKpEJQOpkgM0xB0Je/ZOWlKuHD2UEyuUp7FKGN2jzfCMkzfPkg5iC f96sBb8RtV5G4tVA6Oqgf00dc8AaMac+4i/Fx+YC1kmooxWm/mzHk2pkni9OZdCYxdAKAJsZ 8AI1O2ZeJHVpAgEDo4IBEDCCAQwwEQYJYIZIAYb4QgEBBAQDAgAHMFQGA1UdHwRNMEswSaBH oEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5l c3MxDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMTk5ODA4MTkxOTEyMDZagQ8yMDE4MDgx OTE5MTIwNlowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFAUkiCBOsLJRzMuh2elnJIbV+bBF MB0GA1UdDgQWBBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJg+gIo2VG7EqPRBAJ3Q6sho xP/8pMCk/3UyKbuu4En4aRn+5kAXmjhqJR98uZsR89G5S1I68pn+xhg6FK3gNgC/OLOZ6bRG ABcQGkRov8vvIoJPRRN3JYcAyJSRykY2CZhPsW99pO69qlxS4lRIfIFuflaXs7PY2LTzftsO 6o1cMIIDJTCCAo6gAwIBAgIERktOCjANBgkqhkiG9w0BAQUFADAuMQswCQYDVQQGEwJjYTEQ MA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDAeFw0wNzA1MTYxODAxMzhaFw0xNzA1 MTYxODMxMzhaMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQ cm9kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpd6zp2+OYdJe2JvS/+IlSax3c1GWf xpm/6G11szZ9iRTy0UCpcVZ7e7pEnu/ySNSDN0CLFfj2XMnC2b5YgnuL9/rDz+jVCylLJbuJ HjpYmGWQqG1vbmSUBQeH9TCdTHEqScibjV77r81cfyOpjWe0iETErEUlq5jsnuZOYKkuXQID AQABo4IBTjCCAUowEQYJYIZIAYb4QgEBBAQDAgAHMIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9 MQswCQYDVQQGEwJjYTEQMA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UE AxMEQ1JMMTA5oDegNYYzZmlsZTovL1xcU09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2Nh X2NybGZpbGUuY3JsMCsGA1UdEAQkMCKADzIwMDcwNTE2MTgwMTM4WoEPMjAxNzA1MTYxODMx MzhaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAdBgNV HQ4EFgQU0eQ7z6drsAXxsf5suRJkMtCUG7owDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAE EDAOGwhWNy4xOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAWATjTT62BcA4MaxLVJTG5alA BUYnKzbtbpoZrckpmEVZfcoLooJcgRq58DeGVihhvl9lfUOE3YIQUFxDXA6svFD8Fn99y3Iy RGM+itL/rRdbSAlH2Xa6HLBhjTJff9oa6n67WW/RU0106O8jqS3bcVjWeI0WLh7LKxxHnGz3 TFUwggMwMIICmaADAgECAgQ4xeeqMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkNBMRAw DgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw0wNDA5MjkxNzExNThaFw0w ODA5MjkxNzQxNThaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL EwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8C ehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9S Wl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925 OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj5saS 1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4HPMIHMMB0GA1UdDgQWBBTz8Cwo 5jmnNBmrmpGopmZAkpzicTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO BgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMQ0wCwYDVQQDEwRDUkwxMAsGA1Ud DwQEAwIBBjAfBgNVHSMEGDAWgBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/ MBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI8B1Aa8TTla mxl1BgP6ch4CZUEADT/1xNwEaPveZFajVrURlnKqMfDQ704aNc2qFnLHJDI3dS49vJEJ8LsK Hvd7sf6WqRCuGkF3D8qsIWKxBK6muWdSfKAYWLB/4wDm2CcZDyXt/A3OYFjMzQ5pVBKeAXNA k6fZ32SGLVNvVqc/MIIDMDCCApmgAwIBAgIESCCkSzANBgkqhkiG9w0BAQUFADAyMQswCQYD VQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNMDgwOTI0 MTQzNjA0WhcNMTIwOTI0MTUwNjA0WjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz dDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALyH iI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyfqPfWsTdY zG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZRcdxRZNl H+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824dSee/oDX R8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c4cInKFgB il6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOBzzCBzDAdBgNV HQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxME Q1JMMTALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwDAYD VR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQUFAAOB gQDHUhDfQdNFmborkeOSyqtTmpiIESBES6KULodyCmdHbcoV4L1H5vpjBO0HdUx+YXlIZxUj pTKDv2mowbCAdcWihfW3LjY+3RoqoMu2iR8nSDexR+TesS8drRF9Mrmy30/ddj+sneR7KeaG KL8WGcZBDmxGIvoOaCYGuxsgrC9/LzCCA2gwggLRoAMCAQICBEZLTsUwDQYJKoZIhvcNAQEF BQAwLjELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QwHhcN MDcwNTIyMTQ0MTIxWhcNMTAwNTIyMTUxMTIxWjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALyHiI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyf qPfWsTdYzG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZ RcdxRZNlH+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824 dSee/oDXR8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c 4cInKFgBil6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOCAQow ggEGMB0GA1UdDgQWBBTz8Cwo5jmnNBmrmpGopmZAkpzicTCBjQYDVR0fBIGFMIGCMEWgQ6BB pD8wPTELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QxDTAL BgNVBAMTBENSTDEwOaA3oDWGM2ZpbGU6Ly9cXFNPVFRQUk9EQ0FcQ1JMXHByb2RfZW50cnVz dF9jYV9jcmxmaWxlLmNybDALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU0eQ7z6drsAXxsf5s uRJkMtCUG7owDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkq hkiG9w0BAQUFAAOBgQCQBw6L+mclwk7Z64xW4jbrS1CZpTHFGNmVuow0GbxBdFWHsDNE9H0s 4AUS59qW2T8JQRhm062vhZwpj29bCkOwDgciGq2POfOachGypOnV09x5Dcs3s+5M7c3gpbEP dcO8G7GPIcociDNPPj+Kd8ceoMvcZySp22u4MWuI1bOxyjCCA28wggJXoAMCAQICBEZD+x4w DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNV BAsTB1IgYW5kIEQwHhcNMDgxMDIxMTMyOTM2WhcNMDkwNDIxMTM1OTM2WjBVMQswCQYDVQQG EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UEBRMHMDUw NDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gtt TXg2dN9WsLP92LJQzIYPjdXOXewCcdviTglJfIFKO+RU3O76TPR6pKsZNgPADZL6Q0QHo5I2 ygrRBXCnMOH7xKutmI2QujgX5FW6kEFrHPRom65/XkuMXNW57BjRt+C4hXKU8fHp6WaiKhOM It2WG2jTHU8IYcYnWiiK4dMCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EV dGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDIw HwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFMXxKqPWd83GEHAC aXkPSw+P2UHrMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI hvcNAQEFBQADggEBAClPCYWYRjj5Q0uz74Ldr4FhH4KYkt35rgTXAWR9T2cSLbq6wssHiBS5 YGmM9lsYkQHXc9yPji03n9/Xco/0VjkZY2Fmc03f+3+6WkvvnfAbZFV0HfK1IR/i3hKC5vp9 D8DjcoSXOGwucv7L9iKARJ6jJSXIHl/fTIkt1gqtpfcSAesOhq9u/XO+zxGD8GL1tKF5k1F9 0GN5MQd7HNAZsrwEBDWAO7P3MbCBmOiArjno61cQMUU7k+tgMTt4W2Eeoc0yyzIrRtamz2q8 zbxmnKdEHt140yUXmsxuG04ZM2+iL/MtVD0F69WTAr2JNGsBeeNB8KMGDlCmM8Co2uQOSTkw ggOeMIIChqADAgECAgRGQ/sdMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4MTAyMTEzMjkzNloXDTA5MDQy MTEzNTkzNlowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1Ig YW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALT3bXGkvn4caHYy/u5MXZsEw0q0/s9nj6j7wNkOkyrw394HoLN7 JY404tmf3zCa+qbCXS5eC9hmbU2Rdxo1eZhlB2sZpP/aY8KaHSzUAUcv0LmtQS25qEkSZkLn WSgczRts/EvOf7q0U4COQwI0dP/vBNk+fvJ+jkjVRZxZX32dAgMBAAGjggEcMIIBGDALBgNV HQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODEwMjExMzI5MzZagQ8yMDA5MDIyNTIyNTkzNlow IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBB MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwG A1UEAxMFQ1JMNDIwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYE FCrFDow3ATgAarWOHil+N5udd2xJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcu MQMCBLAwDQYJKoZIhvcNAQEFBQADggEBAFGhTfDY3PVBPb1xQezRSKyd6kfj6d1Gl/rqsOk7 1skHSE89plfdYHMoNEBfSCkr+O2au7hx2DBLLK/zjfaqfpr5Scu8IsYz5LrNKsukP46qwOna 2yprT9VVyCsTuByOnG//9U2CEDIwCZ/GBw1i6MHCXssSdZIjxn5oxmO4OBDHhfBIFXT2vIKC x/yEM+BgU+qWPu5T8V3Q3XR+kCE6jQDRp9cSTJy2Otzw+k+ASXASWO4hzEOH/X8Prd/lx1iS clEK1lOXl5k4gCnQu/KcpM5CGKUhwFjcO9LJb/Xkeab4+Z8yEXSvNrjc5xLuFDW3BLaFPyNa hWsrINpm/kC1goAwggP1MIIC3aADAgECAgQySKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAy MjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx EDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8h4iN +gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJrxUrXXpMn6j31rE3WMxu xUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+6mt42UXHcUWTZR/m Mb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/NuHUnnv6A10fE xgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHCJyhYAYpe sp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzARBglg hkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQk MCKADzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNV HSMEGDAWgBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZm QJKc4nEwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJ KoZIhvcNAQEFBQADggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eV iNDxxycnLUdw6Y9LvXwuQbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvy N+n4R6XO2BxJmjvfuZjNyuv2kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbX g+MQo1CEDf2BPCD2IwG1CiSwN8q7T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI 9HpfD+CXxijdgaE5bPepq0CFtumUAKb0tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E 5s8xggJoMIICZAIBATA5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD VQQLEwdSIGFuZCBEAgRGQ/sdMAcGBSsOAwIaoIIBiTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMzExNTM2NTZaMCMGCSqGSIb3DQEJBDEWBBRJYJQR 3LOeOmLPQl5+lI5BWAQlBjCCASgGCSqGSIb3DQEJDzGCARkwggEVMAoGCCqGSIb3DQMHMAcG BSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMA4GCCqGSIb3DQME AgIAgDANBggqhkiG9w0DBAIBKDAHBgUrDgMCBzAOBgkqhkiG9n0HQgMCAUAwDgYJKoZIhvZ9 B0IDAgEoMA8GCSqGSIb2fQdCCgICAIAwEQYLKwYBBAGBPAcBAQICAgCAMA8GCWCGSAFlAwQB AgICAIAwDwYJYIZIAWUDBAEWAgIAwDAPBglghkgBZQMEASoCAgEAMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBODANBggqhkiG9w0DAgIBKDALBgkqhkiG 9w0BAQEEgYAZ5wG6uFoDAwofzu92qRcG76k3WrqXjHB3b6RsWMe+Jt5xlI2JRzHZbSD10yJu ETUcGMyhvZEVDEwaR3dsN6N3kjF+WpqoK6OAQNA1OO6WmXXfpDJYsucllmfv+JWA0GX4M5Ux uMCHY3dvQnet5UldSEs3dAMT6wfaMlkXHTghlwAAAAAAAA== ----=_NextPart_EE_103656811.38200976-- --===============2075001077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============2075001077==-- From saag-bounces@ietf.org Sun Jan 4 22:54:26 2009 Return-Path: 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 9A8AD28C0FD; Sun, 4 Jan 2009 22:54:26 -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 379893A6A7F for ; Wed, 31 Dec 2008 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] 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 UHbj89CUYEnR for ; Wed, 31 Dec 2008 09:08:49 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 0D4633A6883 for ; Wed, 31 Dec 2008 09:08:47 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A7EB98CD08; Wed, 31 Dec 2008 12:04:09 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AD05D8CCFD; Wed, 31 Dec 2008 12:04:05 -0500 (EST) Message-ID: <495BA5E9.8040305@pobox.com> Date: Wed, 31 Dec 2008 09:03:37 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> In-Reply-To: X-Pobox-Relay-ID: 0A5CA3DC-D75D-11DD-B70C-5720C92D7133-38729857!a-sasl-fastnet.pobox.com X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > We are simply not vigilant enough. This issue has been on our plate > since 2004. > > SHA-1 is next and neither the client side vendors nor the big > Enterprises have pushed to move to SHA-256. There is a simple fix -- a CA can just reorder the extensions prior to issuing a certificate. Mike _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:26 2009 Return-Path: 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 D031828C10A; Sun, 4 Jan 2009 22:54:26 -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 1774A3A6A8F for ; Wed, 31 Dec 2008 09:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 533uxqIY3xxD for ; Wed, 31 Dec 2008 09:42:00 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id DF1653A6A88 for ; Wed, 31 Dec 2008 09:41:59 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2618884yxg.49 for ; Wed, 31 Dec 2008 09:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ZD9TojQEFyfj0W7iXrtxcx8h2S2ZU6g06bJG0wBtyp8=; b=kIpazLlyrapStUZO59ldJG2lZ7HppiZCZwpOxpzxxazz9NWpK2QnKGWK6KMMc8W3Pz S5gPBWBN1uc+jiSPynTi8mZ4jHUBPTcLYu9OgF/mWDVEy1fZNDzpYkEr5Z6vK+aG2qwv 1RpFnEF4Kv1rYydWEaYZFUWJr7/G607jjSxLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=al3rf5cslMjd82x2N/icHAoZW4pRhV4D5WDrEYQvk4I1AoE0U8/3ZaPneE7gt6dV3w v65NcWzAiFtb3Grsx+TWvWp/5LcC8gTQJuyXp6PSomYeFD8QkVacCkM0OMvYnbLmJh5n A6HHO4AE/eGboUvdWMjmoG0a3Nd0lurUk/Osc= Received: by 10.90.30.2 with SMTP id d2mr7680961agd.58.1230745307984; Wed, 31 Dec 2008 09:41:47 -0800 (PST) Received: by 10.90.88.7 with HTTP; Wed, 31 Dec 2008 09:41:47 -0800 (PST) Message-ID: <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> Date: Wed, 31 Dec 2008 12:41:47 -0500 From: "Richard Graveman" To: "RJ Atkinson" In-Reply-To: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> MIME-Version: 1.0 Content-Disposition: inline References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: cfrg@irtf.org, saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Ran, > It would be very helpful if a *set* of mathematicians/cryptographers > could jointly put together a summary of the known attacks on all > the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, > SHA-2, others), *including references to the published literature*. For an expert, authoritative, and incredibly up-to-date tutorial on the state of hash functions, go to http://www.inscrypt.cn/, get the invited talks, and see the one by Preneel. If the intro material is boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not quite in the same boat. For full papers, see IACR eprints 2008/391 for MD5, 2008/469 for SHA-1, and 2006/187 for HMAC with these. Follow the references therein. I avoided sources that cost money to get to, etc. Unfortunately, the ways cryptologists look at these things and the ways the IETF uses them are not always the same, so there is more work to do. Suffice it to say, for a start, there is a big difference between, say: 1. An HMAC based on a fresh key used by IPsec of TLS for a few minutes. 2. An HMAC based on a key stuck in a router and keft there for months or years. 3. A hash used to sign an email. 4. A hash use to sign a root certificate. Rich Graveman _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:27 2009 Return-Path: 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 10D7628C10E; Sun, 4 Jan 2009 22:54:27 -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 CFD433A6A01 for ; Wed, 31 Dec 2008 09:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 SyU3SSkz9CJl for ; Wed, 31 Dec 2008 09:54:49 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9B4AE3A69F8 for ; Wed, 31 Dec 2008 09:54:47 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 88E0F1B777; Wed, 31 Dec 2008 12:50:24 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B7C771B787; Wed, 31 Dec 2008 12:50:19 -0500 (EST) Message-ID: <495BB0B9.9000807@pobox.com> Date: Wed, 31 Dec 2008 09:49:45 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> In-Reply-To: <495BA5E9.8040305@pobox.com> X-Pobox-Relay-ID: 80508BAC-D763-11DD-889F-F83E113D384A-38729857!a-sasl-quonix.pobox.com X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. > > Mike _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:27 2009 Return-Path: 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 475EA28C114; Sun, 4 Jan 2009 22:54:27 -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 141333A6931; Wed, 31 Dec 2008 10:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 w-bAVw1y8JHt; Wed, 31 Dec 2008 10:11:40 -0800 (PST) Received: from relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by core3.amsl.com (Postfix) with ESMTP id 3711F3A68DC; Wed, 31 Dec 2008 10:11:40 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49616 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1LI5XR-0000nh-An; Wed, 31 Dec 2008 18:11:26 +0000 Message-ID: <495BB5D7.7040106@drh-consultancy.demon.co.uk> Date: Wed, 31 Dec 2008 18:11:35 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: <495BB0B9.9000807@pobox.com> X-Enigmail-Version: 0.95.7 X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > Or add a non-critical extension with some randomness in it... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:27 2009 Return-Path: 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 7BB0E28C118; Sun, 4 Jan 2009 22:54:27 -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 AF9CF28C10C for ; Wed, 31 Dec 2008 10:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 xHNwBkNhkfGX for ; Wed, 31 Dec 2008 10:24:31 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id B0A0B28C10B for ; Wed, 31 Dec 2008 10:24:31 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOK0b010078 for ; Wed, 31 Dec 2008 13:24:20 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOKfI010073; Wed, 31 Dec 2008 13:24:20 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:24:20 -0500 Message-ID: <495BB8B6.1040703@mitre.org> Date: Wed, 31 Dec 2008 12:23:50 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: "ietf-pkix@imc.org" , Mike , "cfrg@irtf.org" , "saag@ietf.org" , "ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1159282051==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1159282051== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602050007000404020402" --------------ms010602050007000404020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How about adding an otherName to the SAN? You'd need an OID for random data though. Or the CA could insert a method 4 UUID as a URI in the SAN. That's intentionally random. This might upset anyone wanting to use UUIDs as unique names, though (and these people do exist :). Just thinking out loud. -- Tim Santosh Chokhani wrote: > Private EKU could cause problems if EKU is not otherwise present in the > certificate. > > The certificate may not be usable for intended purpose. Not all clients > may recognize "any key purpose" as intended by 5280. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Mike > Sent: Wednesday, December 31, 2008 12:50 PM > To: ietf-pkix@imc.org > Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org > Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue > CAcertificate > > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > > Mike > > > I wrote: >> There is a simple fix -- a CA can just reorder the extensions prior >> to issuing a certificate. >> >> Mike > --------------ms010602050007000404020402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODIzNTBaMCMGCSqGSIb3DQEJBDEWBBTEu3+INXFh8y7RIME+TF+hrvAoaTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFUNkYNyIak1Rk2H6NPqM7XEBS4j05b8blOT9+hLnMM2Lwb+t6eFS8jW88JJ MaI6+q3G3oh7PiX3BXiOI8IxlNBAi0a6kegxF9sFnt7Kzrw6Tw8OvefCiDISs8QEWbTFv49g ISeuzouWk+0O/27KhDbO0Y+JG4BzqQeu4tCJRnLnAAAAAAAA --------------ms010602050007000404020402-- --===============1159282051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1159282051==-- From saag-bounces@ietf.org Sun Jan 4 22:54:27 2009 Return-Path: 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 B73A728C11C; Sun, 4 Jan 2009 22:54:27 -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 C940E3A6A8A for ; Wed, 31 Dec 2008 10:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 9e85uTCIKFoT for ; Wed, 31 Dec 2008 10:30:55 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7FDD63A6A45 for ; Wed, 31 Dec 2008 10:30:54 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUhx8026624 for ; Wed, 31 Dec 2008 13:30:43 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUh7u026614; Wed, 31 Dec 2008 13:30:43 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:30:43 -0500 Message-ID: <495BBA35.9000404@mitre.org> Date: Wed, 31 Dec 2008 12:30:13 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1946343671==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1946343671== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500070900000409080503" --------------ms060500070900000409080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dr Stephen Henson wrote: > Mike wrote: >> I sent my last message a bit too hastily. Other ideas that I was >> contemplating should have been mentioned including: >> >> - remove any unrecognized extensions >> - remove tumors >> >> Those could potentially cause problems if for some reason they were >> actually needed. This one, though, shouldn't cause trouble: >> >> - add a private EKU with a random number (or two) in the OID >> >> That would not mess up the serial number scheme in use or modify the >> subject name as has been suggested. >> > > Or add a non-critical extension with some randomness in it... Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce 55} or should I? :) -- Tim --------------ms060500070900000409080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODMwMTNaMCMGCSqGSIb3DQEJBDEWBBTDOGnW2taEtjPNTda+B7sp3jwHXjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgI4Tiunxma0T7GovwYWUekJusn0Fg6S544dlebV3nxswPVkGqdvuGRb4yaBq qYonL0ehGR+ZMi1kFYNOLd0bBOibJOtHdubkqmjHMBENsjbiaUnFwd8pN4NW0GIinVLnUTYa 1vfzSaor2vdmDWTBBGF8QAXJPFF76ZsLkkqoz8BJAAAAAAAA --------------ms060500070900000409080503-- --===============1946343671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1946343671==-- From saag-bounces@ietf.org Sun Jan 4 22:54:28 2009 Return-Path: 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 0278A28C120; 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 186943A6931 for ; Wed, 31 Dec 2008 10:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 htAPttVgYQ81 for ; Wed, 31 Dec 2008 10:34:45 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 84C063A68DC for ; Wed, 31 Dec 2008 10:34:45 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYY5w003982 for ; Wed, 31 Dec 2008 13:34:34 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYYd0003979; Wed, 31 Dec 2008 13:34:34 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:34:34 -0500 Message-ID: <495BBB1C.3050404@mitre.org> Date: Wed, 31 Dec 2008 12:34:04 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBA35.9000404@mitre.org> In-Reply-To: <495BBA35.9000404@mitre.org> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0560471348==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0560471348== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406060900010800080503" --------------ms070406060900010800080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Timothy J. Miller wrote: > Dr Stephen Henson wrote: >> Mike wrote: >>> I sent my last message a bit too hastily. Other ideas that I was >>> contemplating should have been mentioned including: >>> >>> - remove any unrecognized extensions >>> - remove tumors >>> >>> Those could potentially cause problems if for some reason they were >>> actually needed. This one, though, shouldn't cause trouble: >>> >>> - add a private EKU with a random number (or two) in the OID >>> >>> That would not mess up the serial number scheme in use or modify the >>> subject name as has been suggested. >>> >> >> Or add a non-critical extension with some randomness in it... > > Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce > 55} or should I? :) draft-01 already: Make that id-ce-magicNumber instead. :) -- Tim --------------ms070406060900010800080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM0MDRaMCMGCSqGSIb3DQEJBDEWBBSSJNMK3zrvAhp1fLThyKuCS2ZbzDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgChOMbV+0oDSDKO7kDjIuxQIjRDbYZag6cll5l/fgLT0BVA+ko8npPtOmf1v ctmCWIwx3wUmGBqLvXlnZIJ17XPwuT8Pkkqwte0q7M4aY3HW0J7UICoVIi9PXBsV75NklUR9 nh8lnb3TROTWQO2G2MG/8Z7Po5Sw1wOvBlDbyElIAAAAAAAA --------------ms070406060900010800080503-- --===============0560471348== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0560471348==-- From saag-bounces@ietf.org Sun Jan 4 22:54:28 2009 Return-Path: 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 471C528C125; 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 DB8E23A69F1 for ; Wed, 31 Dec 2008 10:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 0IlFCsPFOMXZ for ; Wed, 31 Dec 2008 10:35:50 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7FC393A6931 for ; Wed, 31 Dec 2008 10:35:50 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdva006788 for ; Wed, 31 Dec 2008 13:35:39 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdEj006785; Wed, 31 Dec 2008 13:35:39 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:35:39 -0500 Message-ID: <495BBB5D.40507@mitre.org> Date: Wed, 31 Dec 2008 12:35:09 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: "ietf-pkix@imc.org" , Dr Stephen Henson , "cfrg@irtf.org" , "saag@ietf.org" , "ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0721745897==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0721745897== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007000707070000040106" --------------ms010007000707070000040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats chosen prefix attacks as a class. -- Tim --------------ms010007000707070000040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM1MDlaMCMGCSqGSIb3DQEJBDEWBBQ7wSCe4F6a7ye+v4kS0uvOGSEZxjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgCTIqWUo25RX2p72ZoyshHyXDNPdtnFa2cGv0bRgIZSCX0rIi5+1Nl8n3imi L3lCMkQOeE0Ai3QU62e1BzsBzXl4VavVhoeb8JHhzeTZAdrXmxQCJ48CB4R1k+TKB8mtkCCT E1FJ8rPqf9EeE4BVdvHvPSb8zf3mUy3iG4rA9D7zAAAAAAAA --------------ms010007000707070000040106-- --===============0721745897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0721745897==-- From saag-bounces@ietf.org Sun Jan 4 22:54:28 2009 Return-Path: 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 8368728C128; 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 F08D33A6A09 for ; Wed, 31 Dec 2008 10:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 rWDtQKXQyt+6 for ; Wed, 31 Dec 2008 10:54:42 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 14A993A68DC for ; Wed, 31 Dec 2008 10:54:41 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUIe021783 for ; Wed, 31 Dec 2008 13:54:31 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUrK021773; Wed, 31 Dec 2008 13:54:30 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:54:30 -0500 Message-ID: <495BBFC7.4070405@mitre.org> Date: Wed, 31 Dec 2008 12:53:59 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> In-Reply-To: X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: "ietf-pkix@imc.org" , Dr Stephen Henson , "cfrg@irtf.org" , "saag@ietf.org" , "ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362453987==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1362453987== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106060408020209040905" --------------ms010106060408020209040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject to a similar collision generation attack, and the presence of unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim --------------ms010106060408020209040905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODUzNTlaMCMGCSqGSIb3DQEJBDEWBBRvm0ZUBx2kUMXPZMdTcjy9VsI7hTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFfgtFy7Di89XncxZPvVvOWVa1zy05iBeqhstrmEKD0MBObvNiR0lbvnC/Xt VQOKE9jnfS6QSzzE2Iik8Y92fDAhbOWgKdlWcxV9q4+qHjf4Q9aefulpw1SObVxtCcHGhSCt i64UPYyummro3guFQumjkhIxhu8Wcy9LbvN3z1yrAAAAAAAA --------------ms010106060408020209040905-- --===============1362453987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1362453987==-- From saag-bounces@ietf.org Sun Jan 4 22:54:28 2009 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Santosh Chokhani References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=FChring _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:29 2009 Return-Path: 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 13BC828C131; Sun, 4 Jan 2009 22:54: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 5285A3A680F for ; Thu, 1 Jan 2009 07:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 lFkkua6zw2v8 for ; Thu, 1 Jan 2009 07:54:52 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 2F7DC3A65A5 for ; Thu, 1 Jan 2009 07:54:51 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 485131B89A; Thu, 1 Jan 2009 10:52:22 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 43CE11B898; Thu, 1 Jan 2009 10:52:16 -0500 (EST) Message-ID: <495CE68A.5040709@pobox.com> Date: Thu, 01 Jan 2009 07:51:38 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> In-Reply-To: X-Pobox-Relay-ID: 2D5E92AE-D81C-11DD-B34D-F83E113D384A-38729857!a-sasl-quonix.pobox.com X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Is there anything that could be added to RP software to reliably detect and thwart the use of a rogue CA certificate? Or would any attempt to do that just cause too many problems? Mike (who is writing "I am not a security expert" 100 times on the chalkboard) _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:29 2009 Return-Path: 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 51ACD28C136; Sun, 4 Jan 2009 22:54: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 010F93A6982 for ; Fri, 2 Jan 2009 06:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 NcU1Ax-o72n1 for ; Fri, 2 Jan 2009 06:41:40 -0800 (PST) Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by core3.amsl.com (Postfix) with ESMTP id 51D693A6968 for ; Fri, 2 Jan 2009 06:41:40 -0800 (PST) Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id CBF81A2746; Fri, 2 Jan 2009 14:41:17 +0000 (GMT) From: "Peter Hesse" To: "'Mike'" , References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495CE68A.5040709@pobox.com> In-Reply-To: <495CE68A.5040709@pobox.com> Date: Fri, 2 Jan 2009 09:41:15 -0500 Message-ID: <0c6f01c96ce8$2c13d700$843b8500$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclsKjT6Oz0PcIiFQN+3Ed6VEEQeYAAvNWMA Content-Language: en-us X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org > Is there anything that could be added to RP software to reliably > detect and thwart the use of a rogue CA certificate? Or would > any attempt to do that just cause too many problems? Since MD5 is known bad and potentially dangerous at this point, I would suggest that the best client side action would be to fail to verify any signatures created using MD5. This will break some things, especially if existing business processes are relying on a certificate signed with MD5. However, it is a fail-safe and would prevent a rogue CA certificate created in this fashion from being considered trustworthy. And to Santosh's point (and others), my earlier email about removing/replacing trust anchors was not because the self-signed certificates are signed using MD5; I agree the trust anchor public keys are protected using other mechanisms. I am recommending that if CAs do nothing to prevent this kind of attack (non-random serial numbers, issue certificates signed with MD5, issue certificates in an automated, predictable fashion) that those CAs should be removed from trust lists because they are no longer acting in the interest of the relying party--they are an accomplice to the creation of these rogue certificates. --Peter ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 22:54:29 2009 Return-Path: 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 90D6128C13A; Sun, 4 Jan 2009 22:54: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 14E103A6A8E for ; Sun, 4 Jan 2009 14:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 z-PRRherZg8H for ; Sun, 4 Jan 2009 14:02:32 -0800 (PST) Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.19]) by core3.amsl.com (Postfix) with ESMTP id 3A8853A69D0 for ; Sun, 4 Jan 2009 14:02:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost.tue.nl (Postfix) with ESMTP id 01BC45C005; Sun, 4 Jan 2009 23:02:15 +0100 (CET) X-Virus-Scanned: amavisd-new at tue.nl Received: from mailhost.tue.nl ([131.155.2.19]) by localhost (pastinakel.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHJqCkviIVtX; Sun, 4 Jan 2009 23:02:14 +0100 (CET) Received: from EXCHANGE5.campus.tue.nl (xserver6.campus.tue.nl [131.155.6.9]) by mailhost.tue.nl (Postfix) with ESMTP id BACDA5C002; Sun, 4 Jan 2009 23:02:14 +0100 (CET) Received: from webmail11.campus.tue.nl ([131.155.6.51]) by EXCHANGE5.campus.tue.nl with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Jan 2009 23:02:14 +0100 Received: from EXCHANGE11.campus.tue.nl ([131.155.6.30]) by webmail11.campus.tue.nl ([131.155.6.51]) with mapi; Sun, 4 Jan 2009 23:02:14 +0100 From: "Weger, B.M.M. de" To: Paul Hoffman , Yoav Nir Date: Sun, 4 Jan 2009 23:02:36 +0100 Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclurK43+Y7mFmYNToKiFNQb0Pgg2QAChf2w Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E014149035E31@EXCHANGE11.campus.tue.nl> References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2009 22:02:14.0620 (UTC) FILETIME=[1A02D1C0:01C96EB8] X-Mailman-Approved-At: Sun, 04 Jan 2009 22:54:23 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi Paul, > >>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. > > I may have misunderstood the paper, but I think that changes > after the subjectPublicKeyInfo do not affect the attack. Almost correct. A random looking "collision block" has to be inserted somewhere. We chose to insert it in the public key, as that seems the most convenient. Somebody else may find another place where it can be hidden (maybe in a "subject key identifier" field or something, I don't know what would be feasible). Everything after the "collision block" must be copied bitwise into the twin certificate, and must be 'harmless' there. If 'random fluff' is inserted by the CA after the "collision block", this 'random fluff' can be copied into the twin certificate as well, retaining the collision property, and this would indeed be irrelevant to our attack. > >Also, I've updated today and all the "bad" CAs with MD5 > signatures are still in the TAS. > > As was pointed out to me earlier: it does not matter if the > CA has its cert signed with MD5, only whether that CA *signs* > with MD5. RapidSSL, for example, is still signed with MD5 but > is now signing with SHA-1. Correct. Grtz, Benne de Weger _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Jan 4 23:46:40 2009 Return-Path: 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 0F04C3A69D3; Sun, 4 Jan 2009 23:46:40 -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 708B43A69D3 for ; Sun, 4 Jan 2009 23:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] 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 bjgeDOS7FNOB for ; Sun, 4 Jan 2009 23:46:37 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E852E3A67A4 for ; Sun, 4 Jan 2009 23:46:36 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F169929C002; Mon, 5 Jan 2009 09:46:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1F4D629C001; Mon, 5 Jan 2009 09:46:23 +0200 (IST) X-CheckPoint: {4961B8EC-10000-88241DC2-7B6} Received: from gilg-7800.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n057kMfE028615; Mon, 5 Jan 2009 09:46:22 +0200 (IST) Message-Id: From: Yoav Nir To: "B.M.M. de Weger" In-Reply-To: <61150136-EAAD-4609-8AAC-22D57372359F@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 5 Jan 2009 09:46:21 +0200 References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> <7DF2365FF07C0E4E89419D65CCC93C9E014149035E31@EXCHANGE11.campus.tue.nl> <61150136-EAAD-4609-8AAC-22D57372359F@checkpoint.com> X-Mailer: Apple Mail (2.930.3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Oh, OK. I got it now. Eek. On Jan 5, 2009, at 9:37 AM, Yoav Nir wrote: > OK. Now I'm a lot confused :-) > > On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote: > >> Hi Paul, >> >>>>> 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. >>> >>> I may have misunderstood the paper, but I think that changes >>> after the subjectPublicKeyInfo do not affect the attack. >> >> Almost correct. A random looking "collision block" has to be inserted >> somewhere. We chose to insert it in the public key, as that seems >> the most convenient. Somebody else may find another place where >> it can be hidden (maybe in a "subject key identifier" field or >> something, >> I don't know what would be feasible). Everything after the "collision >> block" must be copied bitwise into the twin certificate, and must be >> 'harmless' there. If 'random fluff' is inserted by the CA after the >> "collision block", this 'random fluff' can be copied into the twin >> certificate as well, retaining the collision property, and this >> would indeed be irrelevant to our attack. > > If you inserted a random looking collision block in the public key, > how did your signature on the PKCS#10 request verify? > >> >> >>>> Also, I've updated today and all the "bad" CAs with MD5 >>> signatures are still in the TAS. >>> >>> As was pointed out to me earlier: it does not matter if the >>> CA has its cert signed with MD5, only whether that CA *signs* >>> with MD5. RapidSSL, for example, is still signed with MD5 but >>> is now signing with SHA-1. >> >> Correct. > > Sure, but the other authorities that signed with MD5 (no idea if > they've changed their evil ways) are still there. > Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 00:01:26 2009 Return-Path: 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 8009D3A6936; Mon, 5 Jan 2009 00:01:26 -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 20E393A6936 for ; Mon, 5 Jan 2009 00:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] 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 AImlx3GVz18z for ; Mon, 5 Jan 2009 00:01:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A5D323A67A4 for ; Mon, 5 Jan 2009 00:01:23 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 42E2D29C003; Mon, 5 Jan 2009 09:37:38 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A8C0129C001; Mon, 5 Jan 2009 09:37:12 +0200 (IST) X-CheckPoint: {4961B6C6-10000-88241DC2-7B6} Received: from shiramnew.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n057bCfE026492; Mon, 5 Jan 2009 09:37:12 +0200 (IST) Message-Id: <61150136-EAAD-4609-8AAC-22D57372359F@checkpoint.com> From: Yoav Nir To: "Weger, B.M.M. de" In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E014149035E31@EXCHANGE11.campus.tue.nl> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 5 Jan 2009 09:37:11 +0200 References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> <7DF2365FF07C0E4E89419D65CCC93C9E014149035E31@EXCHANGE11.campus.tue.nl> X-Mailer: Apple Mail (2.930.3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org OK. Now I'm a lot confused :-) On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote: > Hi Paul, > >>>> 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. >> >> I may have misunderstood the paper, but I think that changes >> after the subjectPublicKeyInfo do not affect the attack. > > Almost correct. A random looking "collision block" has to be inserted > somewhere. We chose to insert it in the public key, as that seems > the most convenient. Somebody else may find another place where > it can be hidden (maybe in a "subject key identifier" field or > something, > I don't know what would be feasible). Everything after the "collision > block" must be copied bitwise into the twin certificate, and must be > 'harmless' there. If 'random fluff' is inserted by the CA after the > "collision block", this 'random fluff' can be copied into the twin > certificate as well, retaining the collision property, and this > would indeed be irrelevant to our attack. If you inserted a random looking collision block in the public key, how did your signature on the PKCS#10 request verify? > > >>> Also, I've updated today and all the "bad" CAs with MD5 >> signatures are still in the TAS. >> >> As was pointed out to me earlier: it does not matter if the >> CA has its cert signed with MD5, only whether that CA *signs* >> with MD5. RapidSSL, for example, is still signed with MD5 but >> is now signing with SHA-1. > > Correct. Sure, but the other authorities that signed with MD5 (no idea if they've changed their evil ways) are still there. Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 02:07:42 2009 Return-Path: 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 ED51B3A677E; Mon, 5 Jan 2009 02:07:41 -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 9D16A3A677E; Mon, 5 Jan 2009 02:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.082 X-Spam-Level: X-Spam-Status: No, score=-9.082 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 fT6w0tIs71yO; Mon, 5 Jan 2009 02:07:39 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 507583A63CB; Mon, 5 Jan 2009 02:07:39 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id FAA20784; Mon, 5 Jan 2009 05:06:55 -0500 (EST) From: der Mouse Message-Id: <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 5 Jan 2009 04:57:19 -0500 (EST) To: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >> [...] > This is a different claim than "CAs should stop issuing certs with > MD5 signatures", which is what I as an amateur take away from a quick > scan of the material. What I, as an amateur, take away from it is approximately "MD5 is showing more and more cracks and nobody should use it for anything that needs to withstand a malicious adversary". These may be the best openly published breaks of MD5 at the moment, but I don't for a moment believe nobody has anything better - and I'm quite sure the time to stop using it is now, when it can be done gracefully, rather than in a frantic scramble a few months or years from now when someone publishes a much more blatant break. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 05:27:23 2009 Return-Path: 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 372813A69A2; Mon, 5 Jan 2009 05:27:23 -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 26DD83A69A2 for ; Mon, 5 Jan 2009 05:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 d8p9iXLjzdOq for ; Mon, 5 Jan 2009 05:27:21 -0800 (PST) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by core3.amsl.com (Postfix) with ESMTP id 54BFA3A6940 for ; Mon, 5 Jan 2009 05:27:21 -0800 (PST) Received: from [10.30.20.71] ([70.104.193.39]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KD000BYR2OSD332@vms044.mailsrvcs.net> for saag@ietf.org; Mon, 05 Jan 2009 07:26:57 -0600 (CST) Date: Mon, 05 Jan 2009 08:26:52 -0500 From: RJ Atkinson In-reply-to: <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> To: der Mouse Message-id: MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> Cc: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 5 Jan 2009, at 04:57, der Mouse wrote: > What I, as an amateur, take away from it is approximately "MD5 is > showing more and more cracks and nobody should use it for anything > that > needs to withstand a malicious adversary". Within the CA world, many folks here seem to agree. However, the usage in CAs is rather different from some other modes of operation (e.g. Keyed-Hash, HMAC-Hash). So far, there are no known attacks on those other modes of operation. [If someone knows of a refereed paper that's been published on those latter topics, please share a citation here.] > These may be the best openly published breaks of MD5 at the moment, Mind, there are published "serious attacks" [using NIST's words from their web site] against SHA-0 and SHA-1 also. Timothy Miller seemed to suggest in recent email that perhaps the PKIX WG might enhance the CA structure to increase attack resistance in an algorithm-independent way. Now, may I suggest that folks please LOOK AT and possibly REDUCE/EDIT the CC line as they reply to this thread going forward. Items that are PKIX specific likely belong only on the PKIX list. Ditto for SMIME specific issues to the SMIME list. That would leave only generic comments for the SAAG list. Cheers, Ran _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 08:16:09 2009 Return-Path: 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 3B1D528C0E8; Mon, 5 Jan 2009 08:16:09 -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 66C6F28C0E8; Mon, 5 Jan 2009 08:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_61=0.6, 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 AyQ5gTPZxtCd; Mon, 5 Jan 2009 08:16:06 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2ABA43A67A5; Mon, 5 Jan 2009 08:16:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="p7s'?scan'208";a="27329950" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2009 16:15:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n05GFr4E001120; Mon, 5 Jan 2009 08:15:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05GFrJe025401; Mon, 5 Jan 2009 16:15:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 08:15:51 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 08:15:50 -0800 Message-Id: From: David McGrew To: der Mouse In-Reply-To: <200812240156.UAA04704@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 5 Jan 2009 08:15:48 -0800 References: <20081219172158.9B50F3A6886@core3.amsl.com> <200812191755.mBJHtWQm008375@toasties.srv.cs.cmu.edu> <200812240156.UAA04704@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Jan 2009 16:15:51.0110 (UTC) FILETIME=[E07C9E60:01C96F50] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10557; t=1231172153; x=1232036153; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[saag]=20[Cfrg]=20draft-mcgrew-tss-01 |Sender:=20; bh=n38mgod7BasSjjwfiWqxxyLxvkvfuxInqrL5nJsY4ss=; b=PiGopg82/ZnaSzi/R345Ps5ZNJfgKiRY8woZzsZBJ5YkSkXOha/lFmW/uL G6NuGBCd6IdQ52GmH3fLY2A2SQ0d3WQQ+YL9sqbMXACmmxhQyQKMNatRsGNn rc2k27uIms; Authentication-Results: sj-dkim-3; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: cfrg@ietf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] draft-mcgrew-tss-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0435111980==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0435111980== Content-Type: multipart/signed; boundary=Apple-Mail-26--538121289; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-26--538121289 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 23, 2008, at 4:47 PM, der Mouse wrote: >> - The field multiplication operation is more than a little opaque. >> How were the EXP and LOG tables generated? Is there any convenient >> way to demonstrate that that the tables are actually correct and >> result in an invertible operation? > > The simple thing to do is to build a small program that uses the > tables, and definitions of multiplication and division, from the > draft, and verifies that a*b/a=b and a*b/b=a whenever, respectively, a > or b is nonzero, and that, for any nonzero a, the function x->a*x is a > permutation on the nonzero values of x. I've done this (test program > source is below), and they pass. > > I'm hardly an expert group theorist, but I *think* that the underlying > math will work for any tables that pass those two tests. (Since the > definition of multiplication is symmetric, there is no need to test > separately that x->x*b is a permutation for any nonzero b.) > > As for how EXP and LOG were generated, I don't know, since I didn't > generate them. :) I suspect EXP was generated by computing successive > powers of 3 in the field used by Rijndael (ie, GF(256) with reducing > polynomial 0x11b); the values match values computed that way, so even > if it wasn't it might as well have been. (LOG is just the inverse of > EXP.) My program checks that EXP matches the powers of 3 in GF(256) > with polynomial 0x11b, and that EXP and LOG are inverses. that's right, it's the AES/Rijndael field representation. The draft should state this, since it might be useful to other implementers. > (I actually > would prefer that the spec define multiplication and division in terms > of GF(256) and a particular reducing polynomial rather than in terms > of > tables, even if the operations defined are identical.) The way that the field is currently defined, there are no bit- operations. That was a conscious choice, because the bit/byte conversion is often a point of confusion. Others have also commented that more info on the field should be included, so I think the next version will have an appendix with more information in it. I'd prefer to have minimum information in the normative section, and then have more background in an informative appendix. David > > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > > Here's that test program. It prints any errors it finds, so it should > produce no output. > > #include > #include > #include > > static unsigned char EXP[] = { > 0x01, 0x03, 0x05, 0x0f, 0x11, 0x33, 0x55, 0xff, > 0x1a, 0x2e, 0x72, 0x96, 0xa1, 0xf8, 0x13, 0x35, > 0x5f, 0xe1, 0x38, 0x48, 0xd8, 0x73, 0x95, 0xa4, > 0xf7, 0x02, 0x06, 0x0a, 0x1e, 0x22, 0x66, 0xaa, > 0xe5, 0x34, 0x5c, 0xe4, 0x37, 0x59, 0xeb, 0x26, > 0x6a, 0xbe, 0xd9, 0x70, 0x90, 0xab, 0xe6, 0x31, > 0x53, 0xf5, 0x04, 0x0c, 0x14, 0x3c, 0x44, 0xcc, > 0x4f, 0xd1, 0x68, 0xb8, 0xd3, 0x6e, 0xb2, 0xcd, > 0x4c, 0xd4, 0x67, 0xa9, 0xe0, 0x3b, 0x4d, 0xd7, > 0x62, 0xa6, 0xf1, 0x08, 0x18, 0x28, 0x78, 0x88, > 0x83, 0x9e, 0xb9, 0xd0, 0x6b, 0xbd, 0xdc, 0x7f, > 0x81, 0x98, 0xb3, 0xce, 0x49, 0xdb, 0x76, 0x9a, > 0xb5, 0xc4, 0x57, 0xf9, 0x10, 0x30, 0x50, 0xf0, > 0x0b, 0x1d, 0x27, 0x69, 0xbb, 0xd6, 0x61, 0xa3, > 0xfe, 0x19, 0x2b, 0x7d, 0x87, 0x92, 0xad, 0xec, > 0x2f, 0x71, 0x93, 0xae, 0xe9, 0x20, 0x60, 0xa0, > 0xfb, 0x16, 0x3a, 0x4e, 0xd2, 0x6d, 0xb7, 0xc2, > 0x5d, 0xe7, 0x32, 0x56, 0xfa, 0x15, 0x3f, 0x41, > 0xc3, 0x5e, 0xe2, 0x3d, 0x47, 0xc9, 0x40, 0xc0, > 0x5b, 0xed, 0x2c, 0x74, 0x9c, 0xbf, 0xda, 0x75, > 0x9f, 0xba, 0xd5, 0x64, 0xac, 0xef, 0x2a, 0x7e, > 0x82, 0x9d, 0xbc, 0xdf, 0x7a, 0x8e, 0x89, 0x80, > 0x9b, 0xb6, 0xc1, 0x58, 0xe8, 0x23, 0x65, 0xaf, > 0xea, 0x25, 0x6f, 0xb1, 0xc8, 0x43, 0xc5, 0x54, > 0xfc, 0x1f, 0x21, 0x63, 0xa5, 0xf4, 0x07, 0x09, > 0x1b, 0x2d, 0x77, 0x99, 0xb0, 0xcb, 0x46, 0xca, > 0x45, 0xcf, 0x4a, 0xde, 0x79, 0x8b, 0x86, 0x91, > 0xa8, 0xe3, 0x3e, 0x42, 0xc6, 0x51, 0xf3, 0x0e, > 0x12, 0x36, 0x5a, 0xee, 0x29, 0x7b, 0x8d, 0x8c, > 0x8f, 0x8a, 0x85, 0x94, 0xa7, 0xf2, 0x0d, 0x17, > 0x39, 0x4b, 0xdd, 0x7c, 0x84, 0x97, 0xa2, 0xfd, > 0x1c, 0x24, 0x6c, 0xb4, 0xc7, 0x52, 0xf6, 0x00 }; > > static unsigned char LOG[] = { > 0x00, 0x00, 0x19, 0x01, 0x32, 0x02, 0x1a, 0xc6, > 0x4b, 0xc7, 0x1b, 0x68, 0x33, 0xee, 0xdf, 0x03, > 0x64, 0x04, 0xe0, 0x0e, 0x34, 0x8d, 0x81, 0xef, > 0x4c, 0x71, 0x08, 0xc8, 0xf8, 0x69, 0x1c, 0xc1, > 0x7d, 0xc2, 0x1d, 0xb5, 0xf9, 0xb9, 0x27, 0x6a, > 0x4d, 0xe4, 0xa6, 0x72, 0x9a, 0xc9, 0x09, 0x78, > 0x65, 0x2f, 0x8a, 0x05, 0x21, 0x0f, 0xe1, 0x24, > 0x12, 0xf0, 0x82, 0x45, 0x35, 0x93, 0xda, 0x8e, > 0x96, 0x8f, 0xdb, 0xbd, 0x36, 0xd0, 0xce, 0x94, > 0x13, 0x5c, 0xd2, 0xf1, 0x40, 0x46, 0x83, 0x38, > 0x66, 0xdd, 0xfd, 0x30, 0xbf, 0x06, 0x8b, 0x62, > 0xb3, 0x25, 0xe2, 0x98, 0x22, 0x88, 0x91, 0x10, > 0x7e, 0x6e, 0x48, 0xc3, 0xa3, 0xb6, 0x1e, 0x42, > 0x3a, 0x6b, 0x28, 0x54, 0xfa, 0x85, 0x3d, 0xba, > 0x2b, 0x79, 0x0a, 0x15, 0x9b, 0x9f, 0x5e, 0xca, > 0x4e, 0xd4, 0xac, 0xe5, 0xf3, 0x73, 0xa7, 0x57, > 0xaf, 0x58, 0xa8, 0x50, 0xf4, 0xea, 0xd6, 0x74, > 0x4f, 0xae, 0xe9, 0xd5, 0xe7, 0xe6, 0xad, 0xe8, > 0x2c, 0xd7, 0x75, 0x7a, 0xeb, 0x16, 0x0b, 0xf5, > 0x59, 0xcb, 0x5f, 0xb0, 0x9c, 0xa9, 0x51, 0xa0, > 0x7f, 0x0c, 0xf6, 0x6f, 0x17, 0xc4, 0x49, 0xec, > 0xd8, 0x43, 0x1f, 0x2d, 0xa4, 0x76, 0x7b, 0xb7, > 0xcc, 0xbb, 0x3e, 0x5a, 0xfb, 0x60, 0xb1, 0x86, > 0x3b, 0x52, 0xa1, 0x6c, 0xaa, 0x55, 0x29, 0x9d, > 0x97, 0xb2, 0x87, 0x90, 0x61, 0xbe, 0xdc, 0xfc, > 0xbc, 0x95, 0xcf, 0xcd, 0x37, 0x3f, 0x5b, 0xd1, > 0x53, 0x39, 0x84, 0x3c, 0x41, 0xa2, 0x6d, 0x47, > 0x14, 0x2a, 0x9e, 0x5d, 0x56, 0xf2, 0xd3, 0xab, > 0x44, 0x11, 0x92, 0xd9, 0x23, 0x20, 0x2e, 0x89, > 0xb4, 0x7c, 0xb8, 0x26, 0x77, 0x99, 0xe3, 0xa5, > 0x67, 0x4a, 0xed, 0xde, 0xc5, 0x31, 0xfe, 0x18, > 0x0d, 0x63, 0x8c, 0x80, 0xc0, 0xf7, 0x70, 0x07 }; > > static unsigned char m(unsigned char a, unsigned char b) > { > return((a&&b)?EXP[(LOG[a]+LOG[b])%255]:0); > } > > static unsigned char d(unsigned char a, unsigned char b) > { > if (! b) abort(); > return(a?EXP[(255+LOG[a]-LOG[b])%255]:0); > } > > int main(void); > int main(void) > { > unsigned int a; > unsigned int b; > unsigned int p; > unsigned int q; > char v[256]; > > p = 1; > for (a=0;a<255;a++) > { if (EXP[a] != p) > { printf("EXP[%02x] = %02x, not %02x\n",a,EXP[a],p); > } > p = (p ^ ((p&0x7f)<<1)) ^ ((p&0x80) ? 0x1b : 0); > } > for (a=1;a<256;a++) > { if (EXP[LOG[a]] != a) > { printf("EXP[LOG[%02x]] = %02x\n",a,EXP[LOG[a]]); > } > bzero(&v[0],256); > for (b=1;b<256;b++) > { p = m(a,b); > v[p] = 1; > q = d(p,a); > if (q != b) > { printf("%02x * %02x = %02x / %02x = %02x\n",a,b,p,a,q); > } > q = d(p,b); > if (q != a) > { printf("%02x * %02x = %02x / %02x = %02x\n",a,b,p,b,q); > } > } > for (b=1;b<256;b++) > { if (! v[b]) > { printf("%02x * all misses %02x\n",a,b); > } > } > } > return(0); > } > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-26--538121289 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDnjCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMYIDBDCCAwACAQEwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dyZXcxEzARBgNVBAgM CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEfMB0GCSqGSIb3DQEJ ARYQbWNncmV3QGNpc2NvLmNvbQIBZDAJBgUrDgMCGgUAoIIBZzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAxMDUxNjE1NDlaMCMGCSqGSIb3DQEJBDEWBBTO2X3w GdYtZPvADVgI1zowkyjS8zCBgQYJKwYBBAGCNxAEMXQwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dy ZXcxEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEf MB0GCSqGSIb3DQEJARYQbWNncmV3QGNpc2NvLmNvbQIBZDCBgwYLKoZIhvcNAQkQAgsxdKByMG0x FTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMx ETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMA0G CSqGSIb3DQEBAQUABIIBALHKB7VNrF2gGc12fgBxbJeC0LFtNb2RN94zCs2+wqzJR8lfF2/DRCCX 9gZzs08Qte8hhEkzR8d4GJu2hpnIaUc2BZuX7PYnEoJJcSST1G8+6lYX39bOL6lGReXf7JXs6QGd tDiTs1hLT13QcujyUDHH57yx8SPoxtB411dqcALQ5AIVV/dTLpRGbOYIedfiuuyMZQRKYba15TRa lY4DHgBSM3stkVxCiuVrGW95vn1mvXrc6CUPvv9t5x+wJIPsnIWRYnxn91diqowMO+NamibOic3b GYOkx1mwXPLtNaBc8H+UC5RtBq64flm1HVFhoR1gNRRj1vwT4ylkG6JijLwAAAAAAAA= --Apple-Mail-26--538121289-- --===============0435111980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0435111980==-- From saag-bounces@ietf.org Mon Jan 5 10:15:44 2009 Return-Path: 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 B90393A6962; Mon, 5 Jan 2009 10:15: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 DB3353A688B for ; Mon, 5 Jan 2009 10:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 hS0DOZ2qLKuA for ; Mon, 5 Jan 2009 10:15:42 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F2ED23A63D2 for ; Mon, 5 Jan 2009 10:15:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="p7s'?scan'208";a="224066225" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2009 18:15:29 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05IFTwg004793; Mon, 5 Jan 2009 10:15:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05IFTt1024062; Mon, 5 Jan 2009 18:15:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 10:15:29 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 10:15:28 -0800 Message-Id: <5F8E31B0-CD96-4ED1-83FD-883F0AD78657@cisco.com> From: David McGrew To: RJ Atkinson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 5 Jan 2009 10:15:26 -0800 References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Jan 2009 18:15:28.0611 (UTC) FILETIME=[969C5B30:01C96F61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5059; t=1231179329; x=1232043329; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20attacks=20on=20keyed-hash=20constructions=20[wa s=3A=20Re=3A=20[cfrg]=20Further=20MD5=20breaks=3A=20Creating =20a=20rogue=20CA=20certificate] |Sender:=20; bh=qPhI4WZyZUZj1QJj+mjGuOCPBHDq0ZmCR0YsJEtfVis=; b=jLe9CpwfbLw6qFZiLttqNAHMr3IckcKvlUyuj0O3RSjvj7W+2q0K8ZOsfm i6/sXhyWMPuxWIseEY7CbLm4+1NyhFHB4TZ6C3+eFDZ0FC/ZJ4VwuHnPi5uv rtI8RjGvfhStRo0a+jdc5Ydow8QC76wKUkpfpqtbas/QDxwbVTXZI=; Authentication-Results: sj-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: [saag] attacks on keyed-hash constructions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1333270379==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1333270379== Content-Type: multipart/signed; boundary=Apple-Mail-28--530943312; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-28--530943312 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Ran, On Jan 5, 2009, at 5:26 AM, RJ Atkinson wrote: > > On 5 Jan 2009, at 04:57, der Mouse wrote: >> What I, as an amateur, take away from it is approximately "MD5 is >> showing more and more cracks and nobody should use it for anything =20= >> that >> needs to withstand a malicious adversary". > > Within the CA world, many folks here seem to agree. > > However, the usage in CAs is rather different from > some other modes of operation (e.g. Keyed-Hash, HMAC-Hash). > > So far, there are no known attacks on those other modes of operation. > [If someone knows of a refereed paper that's been published > on those latter topics, please share a citation here.] I'm not sure what you mean by keyed-hash, but here are some attacks =20 that might be relevant. [1] B. Preneel and P. van Oorschot, =93MD-x MAC and building fast MACs =20= from hash functions,=94 Advances in Cryptology =96 Crypto 95 Proceedings, Lecture =20= Notes in Computer Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995. [2] B. Preneel and P. van Oorschot, =93On the security of two MAC =20 algorithms,=94 Advances in Cryptology =96 Eurocrypt 96 Proceedings, Lecture Notes in Computer =20= Science Vol. ??, U. Maurer ed., Springer-Verlag, 1996. RFC 2385 uses the method broken in Section 4.2 of [1]. HMAC seems to be secure given some reasonable assumptions about the =20 hash functions (namely, that the underlying hash has a compression =20 function that is a PRF - no collision resistance is required); see = http://eprint.iacr.org/2006/043 > > >> These may be the best openly published breaks of MD5 at the moment, > > Mind, there are published "serious attacks" [using NIST's words > from their web site] against SHA-0 and SHA-1 also. Timothy > Miller seemed to suggest in recent email that perhaps the PKIX WG > might enhance the CA structure to increase attack resistance in an > algorithm-independent way. > > Now, may I suggest that folks please LOOK AT and possibly > REDUCE/EDIT the CC line as they reply to this thread going forward. > Items that are PKIX specific likely belong only on the PKIX > list. Ditto for SMIME specific issues to the SMIME list. > That would leave only generic comments for the SAAG list. > Done. David --Apple-Mail-28--530943312 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDnjCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMYIDBDCCAwACAQEwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dyZXcxEzARBgNVBAgM CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEfMB0GCSqGSIb3DQEJ ARYQbWNncmV3QGNpc2NvLmNvbQIBZDAJBgUrDgMCGgUAoIIBZzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAxMDUxODE1MjdaMCMGCSqGSIb3DQEJBDEWBBSXSan/ gRHaf9+QPHq7m6l0XczZ+DCBgQYJKwYBBAGCNxAEMXQwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dy ZXcxEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEf MB0GCSqGSIb3DQEJARYQbWNncmV3QGNpc2NvLmNvbQIBZDCBgwYLKoZIhvcNAQkQAgsxdKByMG0x FTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMx ETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMA0G CSqGSIb3DQEBAQUABIIBABVUvthNkhYllLAjRtmJy0tf+00evlXhRTx0bq+50TyFYSf4aSSGW3m+ wkwhu+lCVdLGUZeyfjyDvTDpEPI2Glol6WHM2P0R0L7bL/IC5ZwYv9NAtLuP1e6jOGFzmN9V+bOG 5W5x5qWUCAkJVVScgH2ZAC7+wU2lmWaZMffDY8MKRhsW4Pwjx7r666Yl5LqjWRXLOMLF495KfgFE IdHUcM377I/JRTXvLxZeEs0r6K6+oI+5k/syJLiJ2Gg2OiVX7w6HdODcM6cXNHe5OaXjjvAwFD9K 7Ceckf0Hj42TLmvjEkV31AdWlNEhyl6XFkIDnTaSHRtDtOKgN4fZDIUT5hwAAAAAAAA= --Apple-Mail-28--530943312-- --===============1333270379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1333270379==-- From saag-bounces@ietf.org Mon Jan 5 11:48:03 2009 Return-Path: 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 6BDB228C0EB; Mon, 5 Jan 2009 11:48:03 -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 BCC8528C0EB for ; Mon, 5 Jan 2009 11:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 7dK+hBNhrjKe for ; Mon, 5 Jan 2009 11:48:01 -0800 (PST) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id 7B40628C0E2 for ; Mon, 5 Jan 2009 11:48:01 -0800 (PST) Received: from [10.30.20.71] ([70.104.193.39]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KD000D3IKBBPG83@vms173001.mailsrvcs.net> for saag@ietf.org; Mon, 05 Jan 2009 13:47:36 -0600 (CST) Date: Mon, 05 Jan 2009 14:47:35 -0500 From: RJ Atkinson In-reply-to: <5F8E31B0-CD96-4ED1-83FD-883F0AD78657@cisco.com> To: David McGrew Message-id: <23490481-F122-4CEE-B0DE-57CBD06CCF11@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> <5F8E31B0-CD96-4ED1-83FD-883F0AD78657@cisco.com> Cc: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [saag] attacks on keyed-hash constructions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 5 Jan 2009, at 13:15, David McGrew wrote: > I'm not sure what you mean by keyed-hash, but here are some attacks = > that might be relevant. > > [1] B. Preneel and P. van Oorschot, =93MD-x MAC and building fast MACs = > from hash > functions,=94 Advances in Cryptology =96 Crypto 95 Proceedings, Lecture = > Notes in Computer > Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995. > > [2] B. Preneel and P. van Oorschot, =93On the security of two MAC = > algorithms,=94 Advances > in Cryptology =96 Eurocrypt 96 Proceedings, Lecture Notes in Computer = > Science Vol. ??, > U. Maurer ed., Springer-Verlag, 1996. > > RFC 2385 uses the method broken in Section 4.2 of [1]. > > HMAC seems to be secure given some reasonable assumptions about the = > hash functions (namely, that the underlying hash has a compression = > function that is a PRF - no collision resistance is required); see http:/= /eprint.iacr.org/2006/043 Thank you very much. Pointers to the literature are very helpful. One followup question, if I might, as a non-mathematician here. Does the community agree on whether MD5, SHA-0, SHA-1, and/or SHA-2 meet the assumptions required by the HMAC proofs (e.g. your mention above that the hash "is a PRF -- no collision resistance is required") ??? I do continue to think that an Informational RFC that surveys the use of hash functions -- as used by IETF protocols -- citing the literature (as above) and comparing hash functions and modes would be most helpful. While RFC-4270 was good as far as it went, it did not fully explain what the results meant relative to the modes and algorithms that IETF specifications use -- and of course time moves on and that RFC is now 3 years old. :-) Thanks again, Ran rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 14:50:28 2009 Return-Path: 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 5A9523A6979; Mon, 5 Jan 2009 14:50: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 6EF8728C13D for ; Mon, 5 Jan 2009 14:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 gpFI4CROaWme for ; Mon, 5 Jan 2009 14:50:23 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 74FBC3A6784 for ; Mon, 5 Jan 2009 14:50:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,334,1228089600"; d="scan'208";a="224209674" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2009 22:50:09 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n05MoALW025455; Mon, 5 Jan 2009 14:50:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05MoA78014524; Mon, 5 Jan 2009 22:50:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 14:50:10 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 14:50:09 -0800 Message-Id: <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> From: David McGrew To: RJ Atkinson In-Reply-To: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 5 Jan 2009 14:50:07 -0800 References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Jan 2009 22:50:10.0168 (UTC) FILETIME=[F6625F80:01C96F87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3144; t=1231195810; x=1232059810; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20RFC=20analyzing=20IETF=20use=20of=20hash=20func tions=20[was=3A=20Re=3A=20[Cfrg]=20[saag]=20Further=20MD5=20 breaks=3A=20Creating=20a=20rogue=20CA=20certificate] |Sender:=20; bh=/EOm7o7BFuNGEpF8AWkLvl4Syyir1HDoZeP6RPRibLk=; b=oUT4ALOBNjDsljdVPM+ilLgq4X+HrTd7Qehyy9qeW6vRwPq03+2wXckKZ0 NKtOcHzPvXJ2AFsVwY3vIIY/wUzMHOQl4h9bme9Q0kZbqzksVMB0y760eXcb d1CAE4f3WB; Authentication-Results: sj-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: cfrg@irtf.org, saag@ietf.org Subject: [saag] RFC analyzing IETF use of hash functions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi Ran, I think it is a great idea to document the IETF applications/uses of hashing, and the attacks against particular uses of hashing. It would make a great CFRG informational RFC, if we can find volunteers to contribute to and edit it. I offer to review it. David On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: > > [Distribution trimmed slightly to reduce cross-posting and improve > SNR.] > > On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >> The current MD5 attack is very cool but there's no need to worry >> about >> bad guys doing much with it because it's much, much easier to get >> legitimate CA-issued certs the normal way, you buy them just like >> everyone else does (except that you use someone else's credit card >> and identity, obviously). > > > Two thoughts: > > 1) Protocol Issues > > The IETF ought to be thinking about a wide range of IETF protools > in the same way that Peter thinks about CA security issues above. > > For some IETF protocols, for example all of the IGP authentication > extensions (excepting RFC-2154, AFAICT), active non-cryptographic > attacks are feasible (if not yet seen in the deployed world, AFAICT) > that are much easier than *any* cryptographic attack. Again, and > only by way of example, RFC-4822 discusses some of these that are > specific to RIPv2 authentication. > > For protocols where non-cryptographic attacks are feasible AND > are lower cost than a cryptographic attack, really it does not make > much difference what cryptographic algorithm gets deployed by a user > -- and the IETF's focus should be on improving the underlying > authentication mechanism BEFORE worrying about which cryptographic > algorithms are being deployed. > > Attackers are generally both smart and lazy, so they won't waste > time on an expensive cryptographic attack when a lower effort > non-cryptographic attack exists. > > > 2) Hash algorithm analysis > > It would be very helpful if a *set* of mathematicians/cryptographers > could jointly put together a summary of the known attacks on all > the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, > SHA-2, others), *including references to the published literature*. > > Ideally, this analysis would also include discussion of whether those > attacks apply for those same algorithms when used in the modes > employed > by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5 > or RIPv2 MD5, HMAC-Hash, and so forth). > > This would be most useful to have as an Informational RFC, > and SOON, so that IETF WGs could have some "consensus" document > to refer to -- and to cite explicitly -- if any IETF WGs decide > to make hash algorithm recommendations or decisions. > > I don't understand IRTF process details perfectly, but perhaps > the CFRG chairs might undertake creating such a document as a > near-term official CFRG group project. > > Yours, > > Ran > rja@extremenetworks.com > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 15:10:29 2009 Return-Path: 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 2F07B3A68BA; Mon, 5 Jan 2009 15:10: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 F11E33A68BA; Mon, 5 Jan 2009 15:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 oYj8bWPXJEba; Mon, 5 Jan 2009 15:10:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 779203A684C; Mon, 5 Jan 2009 15:10:26 -0800 (PST) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05N9xhd057971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 16:10:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> Date: Mon, 5 Jan 2009 15:09:58 -0800 To: David McGrew , RJ Atkinson From: Paul Hoffman Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 2:50 PM -0800 1/5/09, David McGrew wrote: >I think it is a great idea to document the IETF applications/uses of hashing, and the attacks against particular uses of hashing. It would make a great CFRG informational RFC, if we can find volunteers to contribute to and edit it. I offer to review it. I will volunteer to update RFC 4270, and I assume that Bruce Schneier would be willing to still be my co-author. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 15:19:46 2009 Return-Path: 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 454023A68BA; Mon, 5 Jan 2009 15:19:46 -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 5CC113A68A5 for ; Mon, 5 Jan 2009 15:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 GUlXxz85Ul1T for ; Mon, 5 Jan 2009 15:19:44 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 70B143A6836 for ; Mon, 5 Jan 2009 15:19:44 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n05NJOQL025577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 18:19:25 -0500 (EST) Date: Mon, 05 Jan 2009 18:19:24 -0500 From: Jeffrey Hutzelman To: Philipp Guehring , Santosh Chokhani Message-ID: <8000C8B414F892C162CFE699@minbar.fac.cs.cmu.edu> In-Reply-To: <200901050658.n056wm4K021787@toasties.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> <200901050658.n056wm4K021787@toasties.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.201.16 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Thursday, January 01, 2009 05:01:33 AM +0100 Philipp Guehring wrote: >> 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. Except that the validation process doesn't actually need to check the signature on a "root certificate", because that signature is not part of the chain. > 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. Hahahahaha! If we all agreed, today, that this is the right approach, and the browser vendors all agreed with us, and they all managed to have updated versions available, by, say, next week... It would be after June before anyone even had the new software. If we're going to propose that browser vendors make a software change, it should not be to remove MD5 support; it should be to allow configuration of which signature algorithms are supported, just as they allow configuration of which TLS ciphersuites are supported. It certainly should _not_ be to generate a warning every time an MD5 signature is used. All that will do is train users to click away security warnings without reading them, which they are already quite good at. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 15:24:18 2009 Return-Path: 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 F355F3A68B9; Mon, 5 Jan 2009 15:24: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 659F53A68B9 for ; Mon, 5 Jan 2009 15:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 297T90ty5jnG for ; Mon, 5 Jan 2009 15:24:16 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 304523A6825 for ; Mon, 5 Jan 2009 15:24:16 -0800 (PST) Received: by bwz14 with SMTP id 14so23374462bwz.13 for ; Mon, 05 Jan 2009 15:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QRHoMSew9AnROqThl/MXfdQQWtRrm4aCkYWCKs4KgLc=; b=VlC0bveSw8MB7FuSFYrPLNtk0UW05gVHblvZx/1HN4+f9OlKWQHvQVDmnjtNhw54dU HmxvENz35Fwk7/yJtJILJV5hdNrcWMDvxj92UxjTxvXe3qEZUgA1082XFDzLdv3KvqAM hsomjvlN4zbELZKrGsNedxibZZwAXfyvT/EVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aK+ZCqLivvs2zd08TK1zHB5vubwuU9WreiV3JHls4TpS6tyAKnG0yJhs9usJAmOlGO sTVUopkDlTvWSMa4aaHpwFLqGFlABPCGkD1V0lhbrgFTfH8RNVY4QKj6mSay39XFsaKp VoyXf34eBv+enhJCExzjOwq0J+/0ayU09VUUo= Received: by 10.180.246.2 with SMTP id t2mr8259536bkh.161.1231197842016; Mon, 05 Jan 2009 15:24:02 -0800 (PST) Received: by 10.181.14.6 with HTTP; Mon, 5 Jan 2009 15:24:01 -0800 (PST) Message-ID: <77ead0ec0901051524x351e0d1dxf1d871f4fb38cae1@mail.gmail.com> Date: Mon, 5 Jan 2009 15:24:01 -0800 From: "Vishwas Manral" To: "Paul Hoffman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> Cc: RJ Atkinson , cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi Paul, I think its a good step forward. I guess the document could instead of taking about each IETF application, talk about uses of hash functions in general and the recomendation about a use of a particular function (i.e. random number generation, secure hash etc). Thanks, Vishwas On Mon, Jan 5, 2009 at 3:09 PM, Paul Hoffman wrote: > At 2:50 PM -0800 1/5/09, David McGrew wrote: >>I think it is a great idea to document the IETF applications/uses of hashing, and the attacks against particular uses of hashing. It would make a great CFRG informational RFC, if we can find volunteers to contribute to and edit it. I offer to review it. > > I will volunteer to update RFC 4270, and I assume that Bruce Schneier would be willing to still be my co-author. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 18:56:36 2009 Return-Path: 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 501F33A6953; Mon, 5 Jan 2009 18:56:36 -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 8BF6E28C0CE; Mon, 5 Jan 2009 18:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 kdfyzHWEtUwo; Mon, 5 Jan 2009 18:56:33 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9CD753A6835; Mon, 5 Jan 2009 18:56:33 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.16.95.209]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LK26z-0000cO-DW; Mon, 05 Jan 2009 21:56:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <496214E9.6010902@mitre.org> References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495D0100.6000200@links.org> <495D1C0A.2080105@links.org> <496214E9.6010902@mitre.org> Date: Mon, 5 Jan 2009 21:53:15 -0500 To: "Timothy J. Miller" From: Stephen Kent Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" , Santosh Chokhani , "mike-list@pobox.com" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 At 8:10 AM -0600 1/5/09, Timothy J. Miller wrote: >Ben Laurie wrote: > >>I am not suggesting that we should fix X.509, I am pointing out, in my >>own roundabout way, that X.509 certs are supposed to have a canonical >>form. But it seems they do not. > >That was last month's major discussion on PKIX. The upshot: there's >no canonical form other than what's in memory. > >-- Tim Tim, Your response is an oversimplification, in several respects. Ben's comment was a bit ill-formed. It's not that certs in general do or do not have a canonical form, but whether a given cert has a canonical representation. If the cert has no extensions, then it does. If it has extensions, then since the top level extension syntax is a SEQUENCE, there the order of extensions in that sequence (when the cert was signed) is definitive. (if that syntax had called for a SET, then DER encoding would impose an order at this level, so use of the SEQUENCE construct here make life a bit easier.) The context in which there is some disagreement is whether an extension needs to be DER encoded below the next level, where it is defined as an OCTET string. If one stops at the OCTET string level, the life is easy and an RP can always encode to DER upon receipt (since the base cert format IS known by all RPs and they are technically capable of encoding it in DER). If one interprets X.509 to require DER for the lower levels of the structure of a cert extension, then a problem can arise. It was noted that a non-critical extension (which therefore ought not be rejected out of hand by an RP) might have a syntax unknown to an RP. Thus the RP needs to assume that what it received is DER encoded when computing the signature, as it has no way to recompute the DER. Steve _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 19:20:45 2009 Return-Path: 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 AEB983A65A5; Mon, 5 Jan 2009 19:20:45 -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 381363A65A5 for ; Mon, 5 Jan 2009 19:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599] 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 4DEIc295qrCX for ; Mon, 5 Jan 2009 19:20:43 -0800 (PST) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id 17A373A63D2 for ; Mon, 5 Jan 2009 19:20:42 -0800 (PST) Received: (qmail 50388 invoked from network); 6 Jan 2009 03:20:30 -0000 Received: from unknown (HELO ?192.168.1.2?) (turners@71.191.9.174 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Jan 2009 03:20:29 -0000 X-YMail-OSG: Z63BL6oVM1m.U4ByW.ZtpB8LfadDgSTjCSmqUkj2rNSI0CFaqLyAOG3Fmnfq6SGVjVCCOPxLGbfMNfJdNH06leCCa2AYTSU7O9hlDmLoBPHn3bx5T4estdF1LorH6mAtva2yvcWIbb4jnYUkp2kyS.OIKqmKOXF_AU3Gjr4blM5PFfn6CUeLQ5ag97NaCewnoJKasS70kLkH5sq77EwY.FeakfqiXlyHZEYh2YTdNM3pteyOd_OY19706R1v084- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4962CE09.5010007@ieca.com> Date: Mon, 05 Jan 2009 22:20:41 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David McGrew References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> In-Reply-To: <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] RFC analyzing IETF use of hash functions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Dave, When the S/MIME WG penned http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we added an appendix that addresses where hashes are located in CMS's SignedData and the attacks against those hashes. I'd be willing to help craft any other wording necessary for S/MIME|CMS. spt David McGrew wrote: > Hi Ran, > > I think it is a great idea to document the IETF applications/uses of > hashing, and the attacks against particular uses of hashing. It would > make a great CFRG informational RFC, if we can find volunteers to > contribute to and edit it. I offer to review it. > > David > > On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: > >> >> [Distribution trimmed slightly to reduce cross-posting and improve SNR.] >> >> On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >>> The current MD5 attack is very cool but there's no need to worry about >>> bad guys doing much with it because it's much, much easier to get >>> legitimate CA-issued certs the normal way, you buy them just like >>> everyone else does (except that you use someone else's credit card >>> and identity, obviously). >> >> >> Two thoughts: >> >> 1) Protocol Issues >> >> The IETF ought to be thinking about a wide range of IETF protools >> in the same way that Peter thinks about CA security issues above. >> >> For some IETF protocols, for example all of the IGP authentication >> extensions (excepting RFC-2154, AFAICT), active non-cryptographic >> attacks are feasible (if not yet seen in the deployed world, AFAICT) >> that are much easier than *any* cryptographic attack. Again, and >> only by way of example, RFC-4822 discusses some of these that are >> specific to RIPv2 authentication. >> >> For protocols where non-cryptographic attacks are feasible AND >> are lower cost than a cryptographic attack, really it does not make >> much difference what cryptographic algorithm gets deployed by a user >> -- and the IETF's focus should be on improving the underlying >> authentication mechanism BEFORE worrying about which cryptographic >> algorithms are being deployed. >> >> Attackers are generally both smart and lazy, so they won't waste >> time on an expensive cryptographic attack when a lower effort >> non-cryptographic attack exists. >> >> >> 2) Hash algorithm analysis >> >> It would be very helpful if a *set* of mathematicians/cryptographers >> could jointly put together a summary of the known attacks on all >> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, >> SHA-2, others), *including references to the published literature*. >> >> Ideally, this analysis would also include discussion of whether those >> attacks apply for those same algorithms when used in the modes employed >> by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5 >> or RIPv2 MD5, HMAC-Hash, and so forth). >> >> This would be most useful to have as an Informational RFC, >> and SOON, so that IETF WGs could have some "consensus" document >> to refer to -- and to cite explicitly -- if any IETF WGs decide >> to make hash algorithm recommendations or decisions. >> >> I don't understand IRTF process details perfectly, but perhaps >> the CFRG chairs might undertake creating such a document as a >> near-term official CFRG group project. >> >> Yours, >> >> Ran >> rja@extremenetworks.com >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Jan 5 19:33:59 2009 Return-Path: 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 9D67428C0EA; Mon, 5 Jan 2009 19:33:59 -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 8E74028C0E0 for ; Mon, 5 Jan 2009 19:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] 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 kOAQn2IeMNs5 for ; Mon, 5 Jan 2009 19:33:58 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 035CE28C0EA for ; Mon, 5 Jan 2009 19:33:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD100M4E5VY41@szxga03-in.huawei.com> for saag@ietf.org; Tue, 06 Jan 2009 11:33:34 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD1005QS5VYD6@szxga03-in.huawei.com> for saag@ietf.org; Tue, 06 Jan 2009 11:33:34 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD100IR75VV1T@szxml05-in.huawei.com> for saag@ietf.org; Tue, 06 Jan 2009 11:33:34 +0800 (CST) Date: Tue, 06 Jan 2009 11:33:31 +0800 From: Sean Shen In-reply-to: <4962CE09.5010007@ieca.com> To: cfrg@irtf.org, saag@ietf.org Message-id: <00be01c96faf$8bea0720$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AclvrcHnT6xNM1OrR8C5J7pd5NPAAQAAK0Ww Subject: Re: [saag] RFC analyzing IETF use of hash functions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi, A draft in CSI work group gives some analysis on hash threats on CGA(RFC3972) and SeND(RFC3971). Hope it also provides valuable info. I will be happy to give review or other possible support for this valuable work. Best, Sean >-----Original Message----- >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >Behalf Of Sean Turner >Sent: Tuesday, January 06, 2009 11:21 AM >To: David McGrew >Cc: cfrg@irtf.org; saag@ietf.org >Subject: Re: [saag] RFC analyzing IETF use of hash functions >[was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate] > >Dave, > >When the S/MIME WG penned >http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we >added an appendix that addresses where hashes are located in >CMS's SignedData and the attacks against those hashes. I'd be >willing to help craft any other wording necessary for S/MIME|CMS. > >spt > >David McGrew wrote: >> Hi Ran, >> >> I think it is a great idea to document the IETF applications/uses of >> hashing, and the attacks against particular uses of hashing. > It would >> make a great CFRG informational RFC, if we can find volunteers to >> contribute to and edit it. I offer to review it. >> >> David >> >> On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: >> >>> >>> [Distribution trimmed slightly to reduce cross-posting and >improve SNR.] >>> >>> On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >>>> The current MD5 attack is very cool but there's no need to >worry about >>>> bad guys doing much with it because it's much, much easier to get >>>> legitimate CA-issued certs the normal way, you buy them just like >>>> everyone else does (except that you use someone else's credit card >>>> and identity, obviously). >>> >>> >>> Two thoughts: >>> >>> 1) Protocol Issues >>> >>> The IETF ought to be thinking about a wide range of IETF protools >>> in the same way that Peter thinks about CA security issues above. >>> >>> For some IETF protocols, for example all of the IGP authentication >>> extensions (excepting RFC-2154, AFAICT), active non-cryptographic >>> attacks are feasible (if not yet seen in the deployed world, AFAICT) >>> that are much easier than *any* cryptographic attack. Again, and >>> only by way of example, RFC-4822 discusses some of these that are >>> specific to RIPv2 authentication. >>> >>> For protocols where non-cryptographic attacks are feasible AND >>> are lower cost than a cryptographic attack, really it does not make >>> much difference what cryptographic algorithm gets deployed by a user >>> -- and the IETF's focus should be on improving the underlying >>> authentication mechanism BEFORE worrying about which cryptographic >>> algorithms are being deployed. >>> >>> Attackers are generally both smart and lazy, so they won't waste >>> time on an expensive cryptographic attack when a lower effort >>> non-cryptographic attack exists. >>> >>> >>> 2) Hash algorithm analysis >>> >>> It would be very helpful if a *set* of mathematicians/cryptographers >>> could jointly put together a summary of the known attacks on all >>> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, >>> SHA-2, others), *including references to the published literature*. >>> >>> Ideally, this analysis would also include discussion of >whether those >>> attacks apply for those same algorithms when used in the >modes employed >>> by various IETF protocols today (e.g. Keyed-Hash as used in >OSPFv2 MD5 >>> or RIPv2 MD5, HMAC-Hash, and so forth). >>> >>> This would be most useful to have as an Informational RFC, >>> and SOON, so that IETF WGs could have some "consensus" document >>> to refer to -- and to cite explicitly -- if any IETF WGs decide >>> to make hash algorithm recommendations or decisions. >>> >>> I don't understand IRTF process details perfectly, but perhaps >>> the CFRG chairs might undertake creating such a document as a >>> near-term official CFRG group project. >>> >>> Yours, >>> >>> Ran >>> rja@extremenetworks.com >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Jan 6 00:44:23 2009 Return-Path: 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 CAFB93A67D2; Tue, 6 Jan 2009 00:44:23 -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 26AEB3A67D2 for ; Tue, 6 Jan 2009 00:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.947, 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 2ueynBh-0qlG for ; Tue, 6 Jan 2009 00:44:22 -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 2D7D33A6778 for ; Tue, 6 Jan 2009 00:44:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7CAC71A20F; Tue, 6 Jan 2009 21:44:06 +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 wXHL334utc-6; Tue, 6 Jan 2009 21:44:06 +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 057771A202; Tue, 6 Jan 2009 21:44:00 +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 78D7D1BE4002; Tue, 6 Jan 2009 21:43:56 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LK7XY-0004kA-BQ; Tue, 06 Jan 2009 21:43:56 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tmiller@mitre.org, ynir@checkpoint.com In-Reply-To: <49621BD4.1020909@mitre.org> Message-Id: Date: Tue, 06 Jan 2009 21:43:56 +1300 Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, pmhesse@geminisecurity.com, ietf-pkix@imc.org, mike-list@pobox.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 "Timothy J. Miller" writes: >The only reliable way to nuke a trusted cert from Windows is touch management >of workstations. It's worse than that, there is no reliable way to remove trusted certs from Windows. See Paul Hoffman's analysis at http://www.proper.com/root-cert-problem/. Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Jan 6 04:31:49 2009 Return-Path: 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 5477D3A68A4; Tue, 6 Jan 2009 04:31:49 -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 EFF9F3A688D for ; Tue, 6 Jan 2009 04:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 LHCYRNCcY5y9 for ; Tue, 6 Jan 2009 04:31:46 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E3C8D3A67AB for ; Tue, 6 Jan 2009 04:31:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,338,1228089600"; d="scan'208";a="119996290" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2009 12:31:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n06CVYBG027276; Tue, 6 Jan 2009 04:31:34 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n06CVY4f017949; Tue, 6 Jan 2009 12:31:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 04:31:33 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 04:31:32 -0800 Message-Id: From: David McGrew To: Sean Turner In-Reply-To: <4962CE09.5010007@ieca.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 6 Jan 2009 04:31:32 -0800 References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> <4962CE09.5010007@ieca.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Jan 2009 12:31:33.0426 (UTC) FILETIME=[B57EC120:01C96FFA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3902; t=1231245094; x=1232109094; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[saag]=20RFC=20analyzing=20IETF=20use=2 0of=20hash=20functions=20[was=3A=20Re=3A=20[Cfrg]=20Further= 20MD5=20breaks=3A=20Creating=20a=20rogue=20CA=20certificate] |Sender:=20; bh=vBJlGO+EuxYjCfoNr5I9eqI7zK265hkDT1IlN//XTWE=; b=PLAhdQD7RHT3CVkmF0Iw2n6ti8TlY4y86x5yKjcEXDFcmCiL4KYnOJs2DX RJtKz7q//pPB+gs0TXDhLNxyyz7RFbrWV+EpE7ym0Llz8q9OJvYlnOdwne6V zq2twmjkUJ; Authentication-Results: sj-dkim-4; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] RFC analyzing IETF use of hash functions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi Sean, On Jan 5, 2009, at 7:20 PM, Sean Turner wrote: > Dave, > > When the S/MIME WG penned http://tools.ietf.org/html/draft-ietf-smime-multisig-05 > we added an appendix that addresses where hashes are located in > CMS's SignedData and the attacks against those hashes. I'd be > willing to help craft any other wording necessary for S/MIME|CMS. great, thanks for volunteering. David > > > spt > > David McGrew wrote: >> Hi Ran, >> I think it is a great idea to document the IETF applications/uses >> of hashing, and the attacks against particular uses of hashing. It >> would make a great CFRG informational RFC, if we can find >> volunteers to contribute to and edit it. I offer to review it. >> David >> On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: >>> >>> [Distribution trimmed slightly to reduce cross-posting and improve >>> SNR.] >>> >>> On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >>>> The current MD5 attack is very cool but there's no need to worry >>>> about >>>> bad guys doing much with it because it's much, much easier to get >>>> legitimate CA-issued certs the normal way, you buy them just like >>>> everyone else does (except that you use someone else's credit card >>>> and identity, obviously). >>> >>> >>> Two thoughts: >>> >>> 1) Protocol Issues >>> >>> The IETF ought to be thinking about a wide range of IETF protools >>> in the same way that Peter thinks about CA security issues above. >>> >>> For some IETF protocols, for example all of the IGP authentication >>> extensions (excepting RFC-2154, AFAICT), active non-cryptographic >>> attacks are feasible (if not yet seen in the deployed world, AFAICT) >>> that are much easier than *any* cryptographic attack. Again, and >>> only by way of example, RFC-4822 discusses some of these that are >>> specific to RIPv2 authentication. >>> >>> For protocols where non-cryptographic attacks are feasible AND >>> are lower cost than a cryptographic attack, really it does not make >>> much difference what cryptographic algorithm gets deployed by a user >>> -- and the IETF's focus should be on improving the underlying >>> authentication mechanism BEFORE worrying about which cryptographic >>> algorithms are being deployed. >>> >>> Attackers are generally both smart and lazy, so they won't waste >>> time on an expensive cryptographic attack when a lower effort >>> non-cryptographic attack exists. >>> >>> >>> 2) Hash algorithm analysis >>> >>> It would be very helpful if a *set* of mathematicians/cryptographers >>> could jointly put together a summary of the known attacks on all >>> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, >>> SHA-2, others), *including references to the published literature*. >>> >>> Ideally, this analysis would also include discussion of whether >>> those >>> attacks apply for those same algorithms when used in the modes >>> employed >>> by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 >>> MD5 >>> or RIPv2 MD5, HMAC-Hash, and so forth). >>> >>> This would be most useful to have as an Informational RFC, >>> and SOON, so that IETF WGs could have some "consensus" document >>> to refer to -- and to cite explicitly -- if any IETF WGs decide >>> to make hash algorithm recommendations or decisions. >>> >>> I don't understand IRTF process details perfectly, but perhaps >>> the CFRG chairs might undertake creating such a document as a >>> near-term official CFRG group project. >>> >>> Yours, >>> >>> Ran >>> rja@extremenetworks.com >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Jan 6 04:32:30 2009 Return-Path: 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 9C6673A6941; Tue, 6 Jan 2009 04:32:30 -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 4419A3A6941 for ; Tue, 6 Jan 2009 04:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 yOgdpOABI2va for ; Tue, 6 Jan 2009 04:32:28 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4AC0C3A6923 for ; Tue, 6 Jan 2009 04:32:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,338,1228089600"; d="scan'208";a="126827219" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2009 12:32:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n06CWFmw002914; Tue, 6 Jan 2009 04:32:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n06CWFet020575; Tue, 6 Jan 2009 12:32:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 04:32:15 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 04:32:14 -0800 Message-Id: <7D2B3E4D-B8DE-46C3-AFE8-48FC88C375AF@cisco.com> From: David McGrew To: Sean Shen In-Reply-To: <00be01c96faf$8bea0720$800c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 6 Jan 2009 04:32:13 -0800 References: <00be01c96faf$8bea0720$800c6f0a@china.huawei.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Jan 2009 12:32:14.0879 (UTC) FILETIME=[CE33FAF0:01C96FFA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4911; t=1231245135; x=1232109135; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[Cfrg]=20[saag]=20RFC=20analyzing=20IET F=20use=20of=20hash=20functions=20[was=3A=20Re=3A=20Further= 20MD5=20breaks=3A=20Creating=20a=20rogue=20CA=20certificate] |Sender:=20; bh=8pGPbrqdajogPvPYDwWEaK+jPD/TzQG4edLtySsWBUU=; b=IUIaXoEV+BUsVHbcj564OxhuUpwbtEw1JHD7a6d/4iOPjovFRz/xD8F2Hp ySRv/6sORPQkzMxrzgwh4++YM7n0WkA+IyTRsgjEylUJzebh2ZW6h2tII1+K QwlSi3MBhln/SI7MTmhXNGNY0salcpPCBUCiPRM7NcLyt1GEKmXfU=; Authentication-Results: sj-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org thanks for volunteering, Sean. On Jan 5, 2009, at 7:33 PM, Sean Shen wrote: > Hi, > A draft in CSI work group gives some analysis on hash threats on > CGA(RFC3972) and SeND(RFC3971). Hope it also provides valuable info. > I will be happy to give review or other possible support for this > valuable > work. > > Best, > > Sean > >> -----Original Message----- >> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, January 06, 2009 11:21 AM >> To: David McGrew >> Cc: cfrg@irtf.org; saag@ietf.org >> Subject: Re: [saag] RFC analyzing IETF use of hash functions >> [was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate] >> >> Dave, >> >> When the S/MIME WG penned >> http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we >> added an appendix that addresses where hashes are located in >> CMS's SignedData and the attacks against those hashes. I'd be >> willing to help craft any other wording necessary for S/MIME|CMS. >> >> spt >> >> David McGrew wrote: >>> Hi Ran, >>> >>> I think it is a great idea to document the IETF applications/uses of >>> hashing, and the attacks against particular uses of hashing. >> It would >>> make a great CFRG informational RFC, if we can find volunteers to >>> contribute to and edit it. I offer to review it. >>> >>> David >>> >>> On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: >>> >>>> >>>> [Distribution trimmed slightly to reduce cross-posting and >> improve SNR.] >>>> >>>> On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >>>>> The current MD5 attack is very cool but there's no need to >> worry about >>>>> bad guys doing much with it because it's much, much easier to get >>>>> legitimate CA-issued certs the normal way, you buy them just like >>>>> everyone else does (except that you use someone else's credit card >>>>> and identity, obviously). >>>> >>>> >>>> Two thoughts: >>>> >>>> 1) Protocol Issues >>>> >>>> The IETF ought to be thinking about a wide range of IETF protools >>>> in the same way that Peter thinks about CA security issues above. >>>> >>>> For some IETF protocols, for example all of the IGP authentication >>>> extensions (excepting RFC-2154, AFAICT), active non-cryptographic >>>> attacks are feasible (if not yet seen in the deployed world, >>>> AFAICT) >>>> that are much easier than *any* cryptographic attack. Again, and >>>> only by way of example, RFC-4822 discusses some of these that are >>>> specific to RIPv2 authentication. >>>> >>>> For protocols where non-cryptographic attacks are feasible AND >>>> are lower cost than a cryptographic attack, really it does not make >>>> much difference what cryptographic algorithm gets deployed by a >>>> user >>>> -- and the IETF's focus should be on improving the underlying >>>> authentication mechanism BEFORE worrying about which cryptographic >>>> algorithms are being deployed. >>>> >>>> Attackers are generally both smart and lazy, so they won't waste >>>> time on an expensive cryptographic attack when a lower effort >>>> non-cryptographic attack exists. >>>> >>>> >>>> 2) Hash algorithm analysis >>>> >>>> It would be very helpful if a *set* of mathematicians/ >>>> cryptographers >>>> could jointly put together a summary of the known attacks on all >>>> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, >>>> SHA-2, others), *including references to the published literature*. >>>> >>>> Ideally, this analysis would also include discussion of >> whether those >>>> attacks apply for those same algorithms when used in the >> modes employed >>>> by various IETF protocols today (e.g. Keyed-Hash as used in >> OSPFv2 MD5 >>>> or RIPv2 MD5, HMAC-Hash, and so forth). >>>> >>>> This would be most useful to have as an Informational RFC, >>>> and SOON, so that IETF WGs could have some "consensus" document >>>> to refer to -- and to cite explicitly -- if any IETF WGs decide >>>> to make hash algorithm recommendations or decisions. >>>> >>>> I don't understand IRTF process details perfectly, but perhaps >>>> the CFRG chairs might undertake creating such a document as a >>>> near-term official CFRG group project. >>>> >>>> Yours, >>>> >>>> Ran >>>> rja@extremenetworks.com >>>> >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/cfrg >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Jan 6 22:35:15 2009 Return-Path: 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 8E5063A68FE; Tue, 6 Jan 2009 22:35:15 -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 9CB3F3A67AF for ; Mon, 5 Jan 2009 06:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 ssyh848pBUmG for ; Mon, 5 Jan 2009 06:11:35 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 5B4C23A67AB for ; Mon, 5 Jan 2009 06:11:34 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EBLrH024501 for ; Mon, 5 Jan 2009 09:11:21 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EBK0m024486; Mon, 5 Jan 2009 09:11:20 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 5 Jan 2009 09:11:20 -0500 Message-ID: <496214E9.6010902@mitre.org> Date: Mon, 5 Jan 2009 08:10:49 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ben Laurie References: <495BA5E9.8040305@pobox.com> <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com> <495D0100.6000200@links.org> <495D1C0A.2080105@links.org> In-Reply-To: <495D1C0A.2080105@links.org> X-Mailman-Approved-At: Tue, 06 Jan 2009 22:35:14 -0800 Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" , Santosh Chokhani , "mike-list@pobox.com" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563785331==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0563785331== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202050805090401080206" --------------ms030202050805090401080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben Laurie wrote: > I am not suggesting that we should fix X.509, I am pointing out, in my > own roundabout way, that X.509 certs are supposed to have a canonical > form. But it seems they do not. That was last month's major discussion on PKIX. The upshot: there's no canonical form other than what's in memory. -- Tim --------------ms030202050805090401080206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTAxMDUxNDEwNDlaMCMGCSqGSIb3DQEJBDEWBBSDPQhbY26jaDdUKPOtB4gReiXvRTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgC2068jNlWSn64YcsvU04REhtJnMOZYhx6rrMPrjFmoq7bvNJ2vIBA91zWAz ypaQhqHqYODjapnJ1CwHoHts1Ff/A0jeBcqdWUMEZFnkJCtZwGruMClZJwLiHeYdzBueizld FQYycjbD+jNX17S8GB288wkFDYJzInkII3V6qwgtAAAAAAAA --------------ms030202050805090401080206-- --===============0563785331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0563785331==-- From saag-bounces@ietf.org Tue Jan 6 22:35:16 2009 Return-Path: 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 4A60E28C12C; Tue, 6 Jan 2009 22:35:16 -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 80E903A6853 for ; Mon, 5 Jan 2009 06:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 iQDjcy+jEIXZ for ; Mon, 5 Jan 2009 06:41:05 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 8562E3A684E for ; Mon, 5 Jan 2009 06:41:05 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EepRb014015 for ; Mon, 5 Jan 2009 09:40:52 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EepET013978; Mon, 5 Jan 2009 09:40:51 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 5 Jan 2009 09:40:51 -0500 Message-ID: <49621BD4.1020909@mitre.org> Date: Mon, 5 Jan 2009 08:40:20 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yoav Nir References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com> <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> In-Reply-To: <230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com> X-Mailman-Approved-At: Tue, 06 Jan 2009 22:35:14 -0800 Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , Peter Hesse , "ietf-pkix@imc.org" , 'Mike' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2052664009==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============2052664009== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070001040001010905020508" --------------ms070001040001010905020508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yoav Nir wrote: >> This sounds great at an IETF mike, but out in the field how do you >> get all those millions of browsers to pull down a new trust list >> that will no longer include CA foobar? >> Can't happen now, and the way things are going, ain't going to >> happen before 2026 either. > There's this one company such that if they use Windows update to > update their browsers, the others will follow. Technically, it's very > easy to get rid of the bad CAs. However, that company is not going to > modify their browsers, not now, probably not in the next few years. I hate to burst your bubble, but there's no automated way to *remove* certs from the MS cert store. You have to script it, and the script can fail any number of different ways. The only reliable way to nuke a trusted cert from Windows is touch management of workstations. -- Tim --------------ms070001040001010905020508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTAxMDUxNDQwMjBaMCMGCSqGSIb3DQEJBDEWBBQSPC3dPpk05tig2GinEiQq/mA0sDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgCWU5pWSQ26W1GWOS1O6u2maERpV1SaNQz8CO2ZgJOiaEVaMd+PWQW5X085o VdD79oEPRc7V/Ow7Ti/y160IXe2663qiEpPLRmHwUBBu65OLBPI7cOE7l88IP6qyat8ct7XX /Jy6tYLuFBDyyiCYutOesjuQK8B5J8QZhwLlDonwAAAAAAAA --------------ms070001040001010905020508-- --===============2052664009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============2052664009==-- From saag-bounces@ietf.org Tue Jan 6 22:35:16 2009 Return-Path: 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 8DB5328C139; Tue, 6 Jan 2009 22:35:16 -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 097223A67A1 for ; Mon, 5 Jan 2009 12:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 cmHxJp4AOgFk for ; Mon, 5 Jan 2009 12:35:36 -0800 (PST) Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by core3.amsl.com (Postfix) with ESMTP id 3F65A3A67CC for ; Mon, 5 Jan 2009 12:35:35 -0800 (PST) Received: from webmail.tugraz.at (webmail.tu-graz.ac.at [129.27.2.204]) by mailrelay2.tugraz.at (8.14.3/8.14.3) with ESMTP id n05KZBbn002295; Mon, 5 Jan 2009 21:35:11 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.7.2 mailrelay2.tugraz.at n05KZBbn002295 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1231187712; bh=kanRSSAYnxzn35yKrNrdwpJFCIfbYiFa0dUg9 4xcLD8=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YOca1YUZTB+Hsu2gj3d7pZ13M9WydL96Rprs9unGJfu1oHB88CmA2sp7LH5Zeipnb eQ+kv9/wuNgUi9ZxsnfPI/72SNQ1Of1kgS56J3tUCK6tjwVNUiot2A/Yrb5/ktfVgOb eCtNDOKIwlpB9S/Ao4xr0SzGMDua80E2XVmME6w= Received: from mk084020178200.a1.net (mk084020178200.a1.net [84.20.178.200]) by webmail.tugraz.at (Horde Framework) with HTTP; Mon, 05 Jan 2009 21:35:08 +0100 Message-ID: <20090105213508.14361u6iuolikois@webmail.tugraz.at> X-Priority: 3 (Normal) Date: Mon, 05 Jan 2009 21:35:08 +0100 From: Christian Rechberger To: RJ Atkinson References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200901051006.FAA20784@Sparkle.Rodents-Montreal.ORG> <5F8E31B0-CD96-4ED1-83FD-883F0AD78657@cisco.com> <23490481-F122-4CEE-B0DE-57CBD06CCF11@extremenetworks.com> In-Reply-To: <23490481-F122-4CEE-B0DE-57CBD06CCF11@extremenetworks.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Organization: Graz University of Technology X-Originating-IP: 84.20.178.200 X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 X-TUG-Backscatter-control: hn0LrPnJ+/fhju8CMzmpjQ X-Spam-Scanner: SpamAssassin 3.002005 X-Spam-Score-relay: 0.1 X-Scanned-By: MIMEDefang 2.65 on 129.27.10.19 X-Mailman-Approved-At: Tue, 06 Jan 2009 22:35:14 -0800 Cc: "ietf-pkix@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" , "ietf-smime@imc.org" Subject: Re: [saag] [Cfrg] attacks on keyed-hash constructions [was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="Yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org UXVvdGluZyBSSiBBdGtpbnNvbiA8cmphQGV4dHJlbWVuZXR3b3Jrcy5jb20+OgoKPgo+PiBITUFD IHNlZW1zIHRvIGJlIHNlY3VyZSBnaXZlbiBzb21lIHJlYXNvbmFibGUgYXNzdW1wdGlvbnMgYWJv dXQgdGhlICAKPj4gaGFzaCBmdW5jdGlvbnMgKG5hbWVseSwgdGhhdCB0aGUgdW5kZXJseWluZyBo YXNoIGhhcyBhIGNvbXByZXNzaW9uICAKPj4gZnVuY3Rpb24gdGhhdCBpcyBhIFBSRiAtIG5vIGNv bGxpc2lvbiByZXNpc3RhbmNlIGlzIHJlcXVpcmVkKTsgc2VlICAKPj4gaHR0cDovL2VwcmludC5p YWNyLm9yZy8yMDA2LzA0Mwo+Cj4gVGhhbmsgeW91IHZlcnkgbXVjaC4KPiBQb2ludGVycyB0byB0 aGUgbGl0ZXJhdHVyZSBhcmUgdmVyeSBoZWxwZnVsLgo+Cj4gT25lIGZvbGxvd3VwIHF1ZXN0aW9u LCBpZiBJIG1pZ2h0LCBhcyBhIG5vbi1tYXRoZW1hdGljaWFuIGhlcmUuCj4KPiBEb2VzIHRoZSBj b21tdW5pdHkgYWdyZWUgb24gd2hldGhlciBNRDUsIFNIQS0wLCBTSEEtMSwgYW5kL29yIFNIQS0y Cj4gbWVldCB0aGUgYXNzdW1wdGlvbnMgcmVxdWlyZWQgYnkgdGhlIEhNQUMgcHJvb2ZzIChlLmcu IHlvdXIgbWVudGlvbgo+IGFib3ZlIHRoYXQgdGhlIGhhc2ggImlzIGEgUFJGIC0tIG5vIGNvbGxp c2lvbiByZXNpc3RhbmNlIGlzCj4gcmVxdWlyZWQiKSA/Pz8KClRoYXQgc2VlbXMgYSB2ZXJ5IHZh bGlkIHF1ZXN0aW9uLCBhbmQgaW5kZWVkIGNyeXB0b2dyYXBoZXJzIGhhdmUgYmVlbiAgCndvcmtp bmcgb24gIFBSRiBwcm9wZXJ0aWVzLCBhbmQgdmlvbGF0aW9ucyBvZiBpdCBjYW4gYmUgdXNlZCB0 byAgCmNvbnN0cnVjdCBhdHRhY2tzIG9uIEhNQUMuCgpBcyBvcHBvc2VkIHRvIHVua2V5ZWQgbW9k ZXMsIG5vbmUgb2YgdGhlIGF0dGFja3Mgd2hpY2ggaGF2ZSBiZWVuICAKZGV2ZWxvcGVkIGluIHJl Y2VudCB5ZWFycyBvbiBITUFDICh3aGVuIGluc3RhbnRpYXRlZCB3aXRoIG9uZSBvZiB0aGUgIApw b3B1bGFyIGhhc2ggZnVuY3Rpb25zKSBhcmUgcHJhY3RpY2FsLgoKU3RpbGwsIHRoZXJlIGFyZSBh dHRhY2tzIG9uIEhNQUMtTUQ0IChzZWUgZS5nLiBbMV0pLCBOTUFDLU1ENSAoc2VlICAKZS5nLiBb MSwyXSkuIEZvciBITUFDLVNIQS0xLCB0aGUgYmVzdCByZXN1bHQgaXMgb24gcmVkdWNlZCB2YXJp YW50cyAgCig2MS82MiBvdXQgb2YgaXRzIDgwIHN0ZXBzLCBzZWUgWzJdKS4KClRvIGNvbmNsdWRl LCBmcm9tIGEgY3J5cHRhbmFseXN0IHBvaW50IG9mIHZpZXc6CkhNQUMtTUQ0OiBwbGVhc2UgZG9u J3QsIGF0dGFja3MgbWlnaHQgYmVjb21lIHByYWN0aWNhbCBhbnl0aW1lCkhNQUMtTUQ1OiBvbmx5 IGNlcnRpZmljYXRpb25hbCBhdHRhY2tzLCBub3RoaW5nIHJlYWwgb3Igc2VyaW91cywgYnV0ICAK TUQ1IGp1c3QgZG9lcyBub3QgbG9vayBsaWtlIGEgZ29vZCBQUkYKSE1BQy1TSEEtMTogb2ssIHNv bWUgc2VjdXJpdHkgbWFyZ2luIGxlZnQKSE1BQy1TSEEtMjogbm8gY29uY3JldGUgY3J5cHRhbmFs eXRpYyByZXN1bHRzLCBtb3N0IGxpa2VseSBvay4KCgpodGgsCiAgQ2hyaXN0aWFuCgoKClsxXSAg UGllcnJlLUFsYWluIEZvdXF1ZSwgR2HDq3RhbiBMZXVyZW50LCBQaG9uZyBOZ3V5ZW46IEZ1bGwg IApLZXktUmVjb3ZlcnkgQXR0YWNrcyBvbiBITUFDL05NQUMtTUQ0IGFuZCBOTUFDLU1ENSwgQ1JZ UFRPIDIwMDcuCgpbMl0gQ2hyaXN0aWFuIFJlY2hiZXJnZXIgYW5kIFZpbmNlbnQgUmlqbWVuOiBP biBBdXRoZW50aWNhdGlvbiB3aXRoICAKSE1BQyBhbmQgTm9uLVJhbmRvbSBQcm9wZXJ0aWVzLCBG aW5hbmNpYWwgQ3J5cHRvZ3JhcGh5IDIwMDcuCgoKLS0gCkNocmlzdGlhbiBSZWNoYmVyZ2VyIDxD aHJpc3RpYW4uUmVjaGJlcmdlckBpYWlrLnR1Z3Jhei5hdD4KS3J5cHRvIEdyb3VwIC0gSUFJSyAt IFRVIEdyYXosIEluZmZlbGRnYXNzZSAxNmEsIEEtODAxMCBHcmF6LCBBdXN0cmlhCmh0dHA6Ly93 d3cuaWFpay50dWdyYXouYXQvY29udGVudC9yZXNlYXJjaC9rcnlwdG8vCnBob25lOiArNDMgKDAp MzE2IDg3MyA1NTM0ICAtLS0gIGZheDogKzQzICgwKTMxNiA4NzMgNTU5NAoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWlsaW5nIGxpc3QKc2Fh Z0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcK From saag-bounces@ietf.org Tue Jan 6 22:35:16 2009 Return-Path: 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 CCC4C28C141; Tue, 6 Jan 2009 22:35:16 -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 77FDA3A68BA for ; Mon, 5 Jan 2009 22:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599] 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 stKMU8BVyQFD for ; Mon, 5 Jan 2009 22:13:05 -0800 (PST) Received: from cs.tau.ac.il (anna.cs.tau.ac.il [132.67.192.229]) by core3.amsl.com (Postfix) with ESMTP id 5E9983A67C0 for ; Mon, 5 Jan 2009 22:13:04 -0800 (PST) Received: from localhost.localdomain (nova.cs.tau.ac.il [132.67.192.133]) by cs.tau.ac.il (Postfix) with ESMTP id F2EB01D181EA; Tue, 6 Jan 2009 08:05:21 +0200 (IST) Received: by localhost.localdomain (Postfix, from userid 3106) id D9F3C1BAC36B; Tue, 6 Jan 2009 08:05:21 +0200 (IST) Received: from localhost (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D740C1B4F056; Tue, 6 Jan 2009 08:05:21 +0200 (IST) Date: Tue, 6 Jan 2009 08:05:21 +0200 (IST) From: Ran Canetti X-X-Sender: canetti@nova.cs.tau.ac.il To: David McGrew In-Reply-To: <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> Message-ID: References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Jan 2009 22:35:14 -0800 Cc: RJ Atkinson , cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 I strongly second. The document might also have some basic recommendations (do-s and dont-s). (the other) Ran On Mon, 5 Jan 2009, David McGrew wrote: > Hi Ran, > > I think it is a great idea to document the IETF applications/uses of hashing, > and the attacks against particular uses of hashing. It would make a great > CFRG informational RFC, if we can find volunteers to contribute to and edit > it. I offer to review it. > > David > > On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote: > >> >> [Distribution trimmed slightly to reduce cross-posting and improve SNR.] >> >> On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >>> The current MD5 attack is very cool but there's no need to worry about >>> bad guys doing much with it because it's much, much easier to get >>> legitimate CA-issued certs the normal way, you buy them just like >>> everyone else does (except that you use someone else's credit card >>> and identity, obviously). >> >> >> Two thoughts: >> >> 1) Protocol Issues >> >> The IETF ought to be thinking about a wide range of IETF protools >> in the same way that Peter thinks about CA security issues above. >> >> For some IETF protocols, for example all of the IGP authentication >> extensions (excepting RFC-2154, AFAICT), active non-cryptographic >> attacks are feasible (if not yet seen in the deployed world, AFAICT) >> that are much easier than *any* cryptographic attack. Again, and >> only by way of example, RFC-4822 discusses some of these that are >> specific to RIPv2 authentication. >> >> For protocols where non-cryptographic attacks are feasible AND >> are lower cost than a cryptographic attack, really it does not make >> much difference what cryptographic algorithm gets deployed by a user >> -- and the IETF's focus should be on improving the underlying >> authentication mechanism BEFORE worrying about which cryptographic >> algorithms are being deployed. >> >> Attackers are generally both smart and lazy, so they won't waste >> time on an expensive cryptographic attack when a lower effort >> non-cryptographic attack exists. >> >> >> 2) Hash algorithm analysis >> >> It would be very helpful if a *set* of mathematicians/cryptographers >> could jointly put together a summary of the known attacks on all >> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, >> SHA-2, others), *including references to the published literature*. >> >> Ideally, this analysis would also include discussion of whether those >> attacks apply for those same algorithms when used in the modes employed >> by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5 >> or RIPv2 MD5, HMAC-Hash, and so forth). >> >> This would be most useful to have as an Informational RFC, >> and SOON, so that IETF WGs could have some "consensus" document >> to refer to -- and to cite explicitly -- if any IETF WGs decide >> to make hash algorithm recommendations or decisions. >> >> I don't understand IRTF process details perfectly, but perhaps >> the CFRG chairs might undertake creating such a document as a >> near-term official CFRG group project. >> >> Yours, >> >> Ran >> rja@extremenetworks.com >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Jan 6 22:35:17 2009 Return-Path: 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 16F1728C147; Tue, 6 Jan 2009 22:35: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 54B1F3A6987 for ; Tue, 6 Jan 2009 06:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 4Wux438AGMVL for ; Tue, 6 Jan 2009 06:08:57 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 74AAE3A68F2 for ; Tue, 6 Jan 2009 06:08:55 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n06E8eNv012872 for ; Tue, 6 Jan 2009 09:08:42 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n06E8dZg012792; Tue, 6 Jan 2009 09:08:39 -0500 Received: from [129.83.200.4] (129.83.200.4) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 6 Jan 2009 09:08:39 -0500 Message-ID: <496365C7.4040804@mitre.org> Date: Tue, 6 Jan 2009 08:08:07 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Mailman-Approved-At: Tue, 06 Jan 2009 22:35:14 -0800 Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" , "pmhesse@geminisecurity.com" , "mike-list@pobox.com" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0197123008==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0197123008== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000103090206070301000309" --------------ms000103090206070301000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > "Timothy J. Miller" writes: > >> The only reliable way to nuke a trusted cert from Windows is touch management >> of workstations. > > It's worse than that, there is no reliable way to remove trusted certs from > Windows. See Paul Hoffman's analysis at > http://www.proper.com/root-cert-problem/. I've corresponded with Paul about that in the past. Root auto-installation can be disabled, users can be blocked from installing roots in both the machine and user store (requires domain GPO, IIRC), and subjectInfoAccess chasing can be disabled (Vista "feature"). Incomplete answer for general users, yes, but it's there nonetheless. Presumably if you're touch managing workstations for trust anchor removal you can verify that these settings are all in place. :) The roots that shouldn't be removed are the ones needed to boot (i.e., validate authenticode signatures). That's more than a few in XP. -- Tim --------------ms000103090206070301000309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTAxMDYxNDA4MDdaMCMGCSqGSIb3DQEJBDEWBBSVwyNPDjTW1JWkewjwuwqOgzrNdzBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgA+rbTeKDp1QXxK7oj1xFjfCEPxO7OdxC1S2IU4zLkMB733Yk1gLoV7Hk7TC i80TgdfLJUXt4tg6SXyQnHSJmsskCtH/mh43NyDoK0zBczSgi7VOO2a6NQV2VI19g0vw8SW6 kx3SuvzveDY6klEiVXBXpbdHJHIQ/VwJj5E5NoC/AAAAAAAA --------------ms000103090206070301000309-- --===============0197123008== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0197123008==-- From saag-bounces@ietf.org Wed Jan 7 15:26:41 2009 Return-Path: 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 79A873A689F; Wed, 7 Jan 2009 15:26:41 -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 A79273A689F for ; Wed, 7 Jan 2009 15:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 7gBEbUARJpXb for ; Wed, 7 Jan 2009 15:26:39 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E34DF3A682D for ; Wed, 7 Jan 2009 15:26:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,228,1231113600"; d="scan'208";a="127325342" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2009 23:26:26 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n07NQQ5B031436; Wed, 7 Jan 2009 15:26:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n07NQQBo020646; Wed, 7 Jan 2009 23:26:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 15:26:26 -0800 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 15:26:26 -0800 Message-Id: <6FD97BCF-12BD-4A70-BAD2-E38549051882@cisco.com> From: David McGrew To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 15:26:24 -0800 References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 07 Jan 2009 23:26:26.0425 (UTC) FILETIME=[5C5C5690:01C9711F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=781; t=1231370787; x=1232234787; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[Cfrg]=20RFC=20analyzing=20IETF=20use=2 0of=20hash=20functions=20[was=3A=20Re=3A=20[saag]=20=09Furth er=20MD5=20breaks=3A=20Creating=20a=20rogue=20CA=20certifica te] |Sender:=20; bh=hlrxnczxwngI/mP3c4OFjBJzuqDhczjvWbjx68p6fE8=; b=nuEt1veRazv//4c/c+WSZc2JVIgHms5zR7It5g6ix2RoX47XD8kkiFv4Jl tejfTIK7ZqoZS2u+azc+yv78UElmVbvzfCc4HmwvWAnUMJeK/xnmeHA+hshC YWI9vFhePX; Authentication-Results: sj-dkim-8; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: RJ Atkinson , cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi Paul, thanks for volunteering. For a CFRG doc it would be good to point out how existing standards can benefit from newer research results, and what open problems could be addressed with future research. David On Jan 5, 2009, at 3:09 PM, Paul Hoffman wrote: > At 2:50 PM -0800 1/5/09, David McGrew wrote: >> I think it is a great idea to document the IETF applications/uses >> of hashing, and the attacks against particular uses of hashing. It >> would make a great CFRG informational RFC, if we can find >> volunteers to contribute to and edit it. I offer to review it. > > I will volunteer to update RFC 4270, and I assume that Bruce > Schneier would be willing to still be my co-author. > > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Jan 7 16:03:30 2009 Return-Path: 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 7418B3A6AB4; Wed, 7 Jan 2009 16:03:30 -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 F0DD93A6AB4 for ; Wed, 7 Jan 2009 16:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 LyPrueTpI0Db for ; Wed, 7 Jan 2009 16:03:23 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 31ED43A6AAE for ; Wed, 7 Jan 2009 16:03:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,229,1231113600"; d="scan'208";a="58639077" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2009 00:03:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0803AZx017391; Wed, 7 Jan 2009 16:03:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n08039lw000332; Thu, 8 Jan 2009 00:03:10 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 16:03:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jan 2009 16:03:06 -0800 Message-ID: In-Reply-To: <6FD97BCF-12BD-4A70-BAD2-E38549051882@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was:Re: Further MD5 breaks: Creating a rogue CA certificate] Thread-Index: AclxH17Je9YRaottSNKO3BQzgLfh3AABAnzg References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com><21E69071-3D71-4882-94DF-80163CE7BEC9@cisco.com> <6FD97BCF-12BD-4A70-BAD2-E38549051882@cisco.com> From: "Joseph Salowey (jsalowey)" To: "David McGrew (mcgrew)" , "Paul Hoffman" X-OriginalArrivalTime: 08 Jan 2009 00:03:07.0560 (UTC) FILETIME=[7C56E280:01C97124] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1859; t=1231372990; x=1232236990; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[saag]=20[Cfrg]=20RFC=20analyzing=20IET F=20use=20of=20hash=20functions=20[was=3ARe=3A=20Further=20M D5=20breaks=3A=20Creating=20a=20rogue=20CA=20certificate] |Sender:=20; bh=6esYxmVx/Saucds6qru53l4eNjYhEfSuM9PNiuJOPXg=; b=g2CijWmqhMfqPTMjTx9YnbJnD37nVbfawyXv1h5JHY7b9DW0cahFcqt05e BlA0ayOyHFMZprW3QT1uqwCquJz0uI7WvHwbew1LU1TShwW4OxLpVsbI3bF4 3uaHD/aFVZ; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: RJ Atkinson , cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was:Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org I think this is an area where there is much ambiguity. When a hash function is used within a protocol it is often unclear what properties are expected from it. This causes problems when a flaw is uncovered and the impact to the protocol is uncertain. I think it would improve things if we were a bit more specific about it. I'd be glad to participate by reviewing, editing, contributing text or whatever else is needed. Cheers, Joe > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On > Behalf Of David McGrew (mcgrew) > Sent: Wednesday, January 07, 2009 3:26 PM > To: Paul Hoffman > Cc: RJ Atkinson; cfrg@irtf.org; saag@ietf.org > Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash > functions [was:Re: Further MD5 breaks: Creating a rogue CA > certificate] > > Hi Paul, > > thanks for volunteering. For a CFRG doc it would be good to > point out how existing standards can benefit from newer > research results, and what open problems could be addressed > with future research. > > David > > On Jan 5, 2009, at 3:09 PM, Paul Hoffman wrote: > > > At 2:50 PM -0800 1/5/09, David McGrew wrote: > >> I think it is a great idea to document the IETF > applications/uses of > >> hashing, and the attacks against particular uses of hashing. It > >> would make a great CFRG informational RFC, if we can find > volunteers > >> to contribute to and edit it. I offer to review it. > > > > I will volunteer to update RFC 4270, and I assume that > Bruce Schneier > > would be willing to still be my co-author. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Jan 7 20:21:44 2009 Return-Path: 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 ; 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 ; 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 ; 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 ) id 1LKmOY-0001mL-AH; Thu, 08 Jan 2009 17:21:22 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, v.paz@uq.edu.au In-Reply-To: <6C62167D152FAD4F91D2D6C8392D1DF005B58E85@UQEXMB1.soe.uq.edu.au> Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 From saag-bounces@ietf.org Wed Jan 7 21:45:53 2009 Return-Path: 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 DF2A828C0FA; Wed, 7 Jan 2009 21:45:52 -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 7850828C0FA for ; Wed, 7 Jan 2009 21:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.527, 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 KpL46+Sxd7Xg for ; Wed, 7 Jan 2009 21:45:51 -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 0A06C3A67A7 for ; Wed, 7 Jan 2009 21:45:50 -0800 (PST) Received: from 68-246-165-160.pools.spcsdns.net (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 n085jJwe008311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 00:45:21 -0500 (EST) Date: Thu, 08 Jan 2009 00:45:19 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , v.paz@uq.edu.au Message-ID: <2125BB6F6871041891AD145D@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901080421.n084LXid025471@raisinbran.srv.cs.cmu.edu> References: <200901080421.n084LXid025471@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: cfrg@irtf.org, tmiller@mitre.org, saag@ietf.org, ietf-pkix@imc.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Thursday, January 08, 2009 05:21:22 PM +1300 Peter Gutmann wrote: > 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 cuts to the root of the problem: there are no contractual relations between a relying party and the cartificate authorities upon whom he relies. As a result, there is no incentive for certificate authorities to adopt practices which benefit the relying party. Instead, the incentive is to adopt practices which benefit the CA and its customers, which are the parties to whom it issues certificates (but _not_ the parties to whom only other CA's issue certificates). Perhaps a solution to this is a new model. Under the new model, each relying party who chooses to participate would punt the trust anchors that come with his or her browser or other software, and instead subscribe to a trust anchor service, which for a fee provides a regularly-maintained list of trust anchors, or perhaps a single trust anchor which signs "root" CA certificates and for which a well-maintained OCSP server is provided. Such a trust anchor service would be an obvious candidate for bundling with ISP services or for sale by security software vendors. The trust anchor service, then, reaches agreements with the various certificate authorities, under which the CA is included in the list of trust anchors in exchange for the CA agreeing to maintain practices which are acceptable to the trust anchor provider. Note that some browser vendors already do essentially this, except that the CA has no contractual obligation to the browser vendor to meet the cirteria for inclusion in the trust anchor list on an ongoing basis, and the browser vendor has no contractual obligation to the users of its product to include only those CA's which meet a suitable set of criteria. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Jan 7 23:51:59 2009 Return-Path: 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 7E90628C103; Wed, 7 Jan 2009 23:51:59 -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 BCC9928C103 for ; Wed, 7 Jan 2009 23:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.375 X-Spam-Level: X-Spam-Status: No, score=-4.375 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JrwFPKJhFZbs for ; Wed, 7 Jan 2009 23:51:55 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 3722E3A681C for ; Wed, 7 Jan 2009 23:51:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2516B9E5B5; Thu, 8 Jan 2009 20:24:04 +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 (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+pssntYkJXL; Thu, 8 Jan 2009 20:24:04 +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 5EB4C9E529; Thu, 8 Jan 2009 20:24:01 +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 BDC571BE4002; Thu, 8 Jan 2009 20:23:55 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LKpFD-0002LS-Ks; Thu, 08 Jan 2009 20:23:55 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, pgut001@cs.auckland.ac.nz, v.paz@uq.edu.au In-Reply-To: <2125BB6F6871041891AD145D@atlantis.pc.cs.cmu.edu> Message-Id: Date: Thu, 08 Jan 2009 20:23:55 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Jeffrey Hutzelman writes: >Perhaps a solution to this is a new model. A good start... >which for a fee provides ... and it just failed right there. Peter :-). _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 04:31:37 2009 Return-Path: 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 9954D3A6814; Thu, 8 Jan 2009 04:31:37 -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 4855C3A6814 for ; Thu, 8 Jan 2009 04:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 a5GWzXq29nRs for ; Thu, 8 Jan 2009 04:31:35 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 677D13A6407 for ; Thu, 8 Jan 2009 04:31:35 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n08CV9b5003696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:31:10 -0500 (EST) Date: Thu, 08 Jan 2009 07:31:09 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , v.paz@uq.edu.au Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: cfrg@irtf.org, tmiller@mitre.org, saag@ietf.org, ietf-pkix@imc.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Thursday, January 08, 2009 08:23:55 PM +1300 Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >> Perhaps a solution to this is a new model. > > A good start... > >> which for a fee provides > > ... and it just failed right there. Perhaps, but it's fairly well essential. That fee is the basis for the trust anchor provider's contractual obligation to the end user. Drop that, and the whole thing falls apart. Note that charging a fee for this service is not absurd. Lots of people (consumers) pay fees for up-to-date lists of virus signatures, phishing sites, spam-blocking rules, and so on. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 05:18:14 2009 Return-Path: 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 CBDBE3A6AE9; Thu, 8 Jan 2009 05:18:14 -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 AC9053A6AD6 for ; Thu, 8 Jan 2009 05:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.774, 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 SVeGslKzfa72 for ; Thu, 8 Jan 2009 05:18:13 -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 EE6483A6AA6 for ; Thu, 8 Jan 2009 05:18:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0A48E199E2; Fri, 9 Jan 2009 02:17:54 +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 gFtiCLKZ2K+g; Fri, 9 Jan 2009 02:17:53 +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 2C9BB19ABA; Fri, 9 Jan 2009 02:17:51 +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 761C91BE4002; Fri, 9 Jan 2009 02:17:44 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LKulc-0003IJ-4X; Fri, 09 Jan 2009 02:17:44 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, pgut001@cs.auckland.ac.nz, v.paz@uq.edu.au In-Reply-To: Message-Id: Date: Fri, 09 Jan 2009 02:17:44 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Jeffrey Hutzelman writes: >Note that charging a fee for this service is not absurd. Lots of people >(consumers) pay fees for up-to-date lists of virus signatures, phishing >sites, spam-blocking rules, and so on. Conceptually it's not absurd, but how are you going to persuade a billion-odd users that they need to pay for something that they've been conditioned to get for free? Will you promise to indemnify them against identity theft (via phishing) if they sign up to your service? What value-add will you offer that will convince the drool-and-click masses to pay for your service? Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 05:58:31 2009 Return-Path: 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 7E9B13A6A4D; Thu, 8 Jan 2009 05:58:31 -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 157203A6A4D; Thu, 8 Jan 2009 05:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 k+mF-BH8yUVz; Thu, 8 Jan 2009 05:58:29 -0800 (PST) Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 366653A6862; Thu, 8 Jan 2009 05:58:29 -0800 (PST) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKvOT-0007Ly-J8; Thu, 08 Jan 2009 08:57:53 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKvOS-0006Ca-R3; Thu, 08 Jan 2009 08:57:52 -0500 Date: Thu, 8 Jan 2009 08:57:52 -0500 From: Theodore Tso To: Peter Gutmann Message-ID: <20090108135752.GC20121@mit.edu> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Cc: v.paz@uq.edu.au, cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, tmiller@mitre.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, Jan 09, 2009 at 02:17:44AM +1300, Peter Gutmann wrote: > > Conceptually it's not absurd, but how are you going to persuade a > billion-odd users that they need to pay for something that they've > been conditioned to get for free? Will you promise to indemnify > them against identity theft (via phishing) if they sign up to your > service? What value-add will you offer that will convince the > drool-and-click masses to pay for your service? Especially since the market has already come up with a solution that involves the merchants and the credit card companies bearing the burden of most fraud losses... - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 06:08:46 2009 Return-Path: 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 326F83A6AB3; Thu, 8 Jan 2009 06:08:46 -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 AF8813A6AB3 for ; Thu, 8 Jan 2009 06:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 wUbauwY2xpl2 for ; Thu, 8 Jan 2009 06:08:43 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B380D3A676A for ; Thu, 8 Jan 2009 06:08:43 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n08E8MJp005143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:08:22 -0500 (EST) Date: Thu, 08 Jan 2009 09:08:22 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , v.paz@uq.edu.au Message-ID: <34201D87D99D2E7BF3467C9A@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: cfrg@irtf.org, tmiller@mitre.org, saag@ietf.org, ietf-pkix@imc.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Friday, January 09, 2009 02:17:44 AM +1300 Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >> Note that charging a fee for this service is not absurd. Lots of people >> (consumers) pay fees for up-to-date lists of virus signatures, phishing >> sites, spam-blocking rules, and so on. > > Conceptually it's not absurd, but how are you going to persuade a > billion-odd users that they need to pay for something that they've been > conditioned to get for free? Will you promise to indemnify them against > identity theft (via phishing) if they sign up to your service? What > value-add will you offer that will convince the drool-and-click masses to > pay for your service? Convince the insurance companies to give discounts on "identity theft" insurance (yes, this product exists and is pretty common; it covers the costs of tracking down and fixing the results of fraud that, under the present system, are borne _not_ by the banks or merchants but by the individual who was impersonated). Convince the security software companies to add this service to their bundles. Plenty of people buy that stuff. Convince the banks to change their rules to make you responsible for unauthorized access if it would have been prevented by such a service and you weren't using one. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 06:16:58 2009 Return-Path: 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 C076828C148; Thu, 8 Jan 2009 06:16:58 -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 999AA28C148 for ; Thu, 8 Jan 2009 06:16:57 -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 2qPvtxPjoEOE for ; Thu, 8 Jan 2009 06:16:56 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C2E3928C0F4 for ; Thu, 8 Jan 2009 06:16:56 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n08ELMRC009871; Thu, 8 Jan 2009 08:21:24 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 08:16:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 08:16:33 -0600 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <20090108135752.GC20121@mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclxmTjSC5+Op89uTFeG68Sdc7cdQAAAWcIA References: <20090108135752.GC20121@mit.edu> From: "Eric Gray" To: "Theodore Tso" , "Peter Gutmann" X-OriginalArrivalTime: 08 Jan 2009 14:16:34.0249 (UTC) FILETIME=[B5E78B90:01C9719B] Cc: v.paz@uq.edu.au, cfrg@irtf.org, tmiller@mitre.org, saag@ietf.org, ietf-pkix@imc.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Ted, The notion of merchants and bankers "bearing the burden" is a great fiction - at least if you're considering them as a group. In individual cases, individual merchants/bankers will absorb losses, but either that means they go out of business (which we see sometimes) or they survive to defray their losses by charging consumers more for their products and services. Even in the cases where merchants/bankers go out of business, the consumer ends up absorbing the loss as a result of reduction in the competitive market arena and increased "risk" costs associated with the remaining merchants/bankers. Since the consumer ultimately pays the price in any case, perhaps a good argument can be made for paying a portion of it up front? -- Eric -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Theodore Tso Sent: Thursday, January 08, 2009 8:58 AM To: Peter Gutmann Cc: v.paz@uq.edu.au; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org; tmiller@mitre.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate On Fri, Jan 09, 2009 at 02:17:44AM +1300, Peter Gutmann wrote: > > Conceptually it's not absurd, but how are you going to persuade a > billion-odd users that they need to pay for something that they've > been conditioned to get for free? Will you promise to indemnify > them against identity theft (via phishing) if they sign up to your > service? What value-add will you offer that will convince the > drool-and-click masses to pay for your service? Especially since the market has already come up with a solution that involves the merchants and the credit card companies bearing the burden of most fraud losses... - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 06:51:23 2009 Return-Path: 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 8F1623A6977; Thu, 8 Jan 2009 06:51:23 -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 631EF3A690B; Thu, 8 Jan 2009 06:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 IQB1LHE-8k71; Thu, 8 Jan 2009 06:51:21 -0800 (PST) Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 8FC183A6868; Thu, 8 Jan 2009 06:51:21 -0800 (PST) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKwDr-0007QE-7O; Thu, 08 Jan 2009 09:50:59 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKwDq-0006X6-A8; Thu, 08 Jan 2009 09:50:58 -0500 Date: Thu, 8 Jan 2009 09:50:58 -0500 From: Theodore Tso To: Eric Gray Message-ID: <20090108145058.GE20121@mit.edu> References: <20090108135752.GC20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Cc: v.paz@uq.edu.au, cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, tmiller@mitre.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Thu, Jan 08, 2009 at 08:16:33AM -0600, Eric Gray wrote: > The notion of merchants and bankers "bearing the burden" is a > great fiction - at least if you're considering them as a group. In > individual cases, individual merchants/bankers will absorb losses, > but either that means they go out of business (which we see > sometimes) or they survive to defray their losses by charging > consumers more for their products and services. I didn't say it was a good way to run a railroad --- just as having more and more people read their news on-line for free, while reporters are paid via a business model that depends on rapidly diminishing advertising revenues for print and on-line banner ads, plus the vanishingly small number of people willing to pay for dead-tree versions of newspapers is a great way of running things. But the problem is very similar; if at least in the US, consumers are used to a model where they only pay for the costs of fraud via a surcharge which is hidden in the cost of the on-line merchant's prices, how do you convince them that it is worthwhile to pay for a trust certification service? Especially given that a merchant is still going to have to pay the 3% credit card fee to the credit card companies, which ends up showing up in the price of goods and/or services? > Since the consumer ultimately pays the price in any case, > perhaps a good argument can be made for paying a portion of it up > front? >From a public policy POV, perhaps. How you actually convince the consumers, merchants, credit card companies, and the rest of the system to transition from the current scheme to this new scheme is much more difficult than writing an RFC, alas. (And as we all know, writing and publishing RFC is no guarantee that the market will listen to us.) - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 07:11:48 2009 Return-Path: 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 ADAC13A68D6; Thu, 8 Jan 2009 07:11:48 -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 9278A3A68BD for ; Thu, 8 Jan 2009 07:11:47 -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 FFWVzrm7n+OZ for ; Thu, 8 Jan 2009 07:11:46 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id AE27E3A68B2 for ; Thu, 8 Jan 2009 07:11:46 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n08FG9QX024067; Thu, 8 Jan 2009 09:16:10 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 09:11:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 09:11:21 -0600 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0468D3FE@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <20090108145058.GE20121@mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate Thread-Index: AclxoItZqFMiZ4aWQ2O+goxB+44hCgAAUwRw References: <20090108135752.GC20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> <20090108145058.GE20121@mit.edu> From: "Eric Gray" To: "Theodore Tso" X-OriginalArrivalTime: 08 Jan 2009 15:11:22.0212 (UTC) FILETIME=[5DAEE240:01C971A3] Cc: v.paz@uq.edu.au, cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, tmiller@mitre.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Ted, I completely agree that publishing an RFC will never solve world hunger, but it could lay the ground work for solutions to some of our other problems. You mention on-line news. There's news, and then there's not so accurate news reporting. How do you distinguish news from bad reporting - or even out-right lies? Usually, by reputation. But's what is anyone's reputation worth if anyone can destroy it while pretending to be them? As a result, some organizations already pay for news-feeds from known (verifiably) reliable sources. Because on-line news is also valuable because it's quickly delivered. No matter how you get it, it's not necessarily free. As the Heinlein acronym "TANSTAAFL" says, there ain't no such thing as a free lunch. And I suspect that an increasingly large number of people are coming to really understand that. -- E// -----Original Message----- From: Theodore Tso [mailto:tytso@mit.edu] Sent: Thursday, January 08, 2009 9:51 AM To: Eric Gray Cc: Peter Gutmann; v.paz@uq.edu.au; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org; tmiller@mitre.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate Importance: High On Thu, Jan 08, 2009 at 08:16:33AM -0600, Eric Gray wrote: > The notion of merchants and bankers "bearing the burden" is a > great fiction - at least if you're considering them as a group. In > individual cases, individual merchants/bankers will absorb losses, > but either that means they go out of business (which we see > sometimes) or they survive to defray their losses by charging > consumers more for their products and services. I didn't say it was a good way to run a railroad --- just as having more and more people read their news on-line for free, while reporters are paid via a business model that depends on rapidly diminishing advertising revenues for print and on-line banner ads, plus the vanishingly small number of people willing to pay for dead-tree versions of newspapers is a great way of running things. But the problem is very similar; if at least in the US, consumers are used to a model where they only pay for the costs of fraud via a surcharge which is hidden in the cost of the on-line merchant's prices, how do you convince them that it is worthwhile to pay for a trust certification service? Especially given that a merchant is still going to have to pay the 3% credit card fee to the credit card companies, which ends up showing up in the price of goods and/or services? > Since the consumer ultimately pays the price in any case, > perhaps a good argument can be made for paying a portion of it up > front? >From a public policy POV, perhaps. How you actually convince the consumers, merchants, credit card companies, and the rest of the system to transition from the current scheme to this new scheme is much more difficult than writing an RFC, alas. (And as we all know, writing and publishing RFC is no guarantee that the market will listen to us.) - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 08:34:57 2009 Return-Path: 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 E79723A6B08; Thu, 8 Jan 2009 08:34:57 -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 096FE3A6B08; Thu, 8 Jan 2009 08:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 oexuEHnIUaqu; Thu, 8 Jan 2009 08:34:56 -0800 (PST) Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 3B8643A6AC3; Thu, 8 Jan 2009 08:34:56 -0800 (PST) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKxq3-0007Zm-7B; Thu, 08 Jan 2009 11:34:31 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKxq2-0007BP-72; Thu, 08 Jan 2009 11:34:30 -0500 Date: Thu, 8 Jan 2009 11:34:30 -0500 From: Theodore Tso To: Eric Gray Message-ID: <20090108163430.GH20121@mit.edu> References: <20090108135752.GC20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> <20090108145058.GE20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D3FE@eusrcmw721.eamcs.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0468D3FE@eusrcmw721.eamcs.ericsson.se> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Cc: v.paz@uq.edu.au, cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org, tmiller@mitre.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Thu, Jan 08, 2009 at 09:11:21AM -0600, Eric Gray wrote: > As a result, some organizations already pay for news-feeds > from known (verifiably) reliable sources. Because on-line news is > also valuable because it's quickly delivered. No matter how you > get it, it's not necessarily free. Some do; some of us even subscribe to dead-tree versions of the newspapers even though we do most of our reading on-line, on the general theory that it's good public policy to support the Fourth Estate (since they serve a critical function keeping the government honest), even though we do most of our news reading online. The problem is very few people are willing to pay for on-line news when they can get the New York Times at http://www.nytimes.com (and many other news sources) for free. > As the Heinlein acronym "TANSTAAFL" says, there ain't no > such thing as a free lunch. And I suspect that an increasingly > large number of people are coming to really understand that. Yes, but there are a huge number of people who are used to receiving a lot of these services either for free, or bundled into prices (which have gotten cheaper as a result of e-commerce). This is basically the classic Tragedy of the Commons problem; how many people can *honestly* say that they've never gone to Best Buy or Circuit City to examine some device or gadget in person, and then gone on to buy it on-line because it was cheaper? And did so even though it should be *obvious* that the TANSTAAFL principle applied, and would in the long-run lead to the weakening or disappearance of the bricks-and-morter stores? - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 09:07:54 2009 Return-Path: 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 8C4C53A68E0; Thu, 8 Jan 2009 09:07:54 -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 7E3C13A6878 for ; Thu, 8 Jan 2009 06:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ZseD9IB4gLZ4 for ; Thu, 8 Jan 2009 06:21:44 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id F22043A6859 for ; Thu, 8 Jan 2009 06:21:43 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08ELTmN012803 for ; Thu, 8 Jan 2009 09:21:30 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08ELSka012744; Thu, 8 Jan 2009 09:21:28 -0500 Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 8 Jan 2009 09:21:28 -0500 Message-ID: <49660BCB.8000809@mitre.org> Date: Thu, 8 Jan 2009 08:20:59 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jeffrey Hutzelman References: In-Reply-To: X-Mailman-Approved-At: Thu, 08 Jan 2009 09:07:53 -0800 Cc: "v.paz@uq.edu.au" , "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682656238==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1682656238== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306050806080101080606" --------------ms000306050806080101080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > Note that charging a fee for this service is not absurd. Lots of people > (consumers) pay fees for up-to-date lists of virus signatures, phishing > sites, spam-blocking rules, and so on. Actually, most consumers keep these up-to-date only as long as the free trial period given to them when they bought the computer lasts, and then cease to care. The core business for these companies is business contracts. -- Tim --------------ms000306050806080101080606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTAxMDgxNDIwNTlaMCMGCSqGSIb3DQEJBDEWBBRhJ8OPKskpKyb409QzoLQfobWV4jBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgDBLEFj0m7V/YBruCeqkQOL5+50I4wjSl4F7hbwnsA/gW3p7PxNvfJS69qTn 6YVdQIoNfYEsr4bhwHtn1fz373t0puwCZG3u4koo1P7KuagH0ja1JKvuJBwHNWI2wU+6g9CF xKN5jCoDe+7QmWB1WLOpC1S/M6mpmc+c3XbX4y2EAAAAAAAA --------------ms000306050806080101080606-- --===============1682656238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1682656238==-- From saag-bounces@ietf.org Thu Jan 8 10:21:15 2009 Return-Path: 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 210DA3A68F0; Thu, 8 Jan 2009 10:21:15 -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 27AA13A68F0; Thu, 8 Jan 2009 10:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] 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 3oHnPUBwz5ij; Thu, 8 Jan 2009 10:21:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1F2293A6887; Thu, 8 Jan 2009 10:21:12 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IKuSG064552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:20:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090108163430.GH20121@mit.edu> References: <20090108135752.GC20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> <20090108145058.GE20121@mit.edu> <941D5DCD8C42014FAF70FB7424686DCF0468D3FE@eusrcmw721.eamcs.ericsson.se> <20090108163430.GH20121@mit.edu> Date: Thu, 8 Jan 2009 10:20:55 -0800 To: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org From: Paul Hoffman Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Folks: is rehashing the blue-sky discussions of how to create a better trust model for SSL without a stable proposal to look at really a good use of the the CFRG, SAAG, S/MIME, and PKIX mailing lists? If you want to be serious about this, please write an Internet Draft and set up a mailing list for the discussion. Invite people from these lists to join, and maybe announce revisions to your draft. Be sure to invite people from the Mozilla security community: they are having their own (perpetually repeating) discussion of this, again without a stable document to comment on. We *can* change the security model, but not with the current method of discussion-without-focus. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 10:34:52 2009 Return-Path: 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 DC7173A68A2; Thu, 8 Jan 2009 10:34:52 -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 AA58E28C0F9 for ; Thu, 8 Jan 2009 10:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NSseJSR0za5f for ; Thu, 8 Jan 2009 10:25:10 -0800 (PST) Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [156.80.1.73]) by core3.amsl.com (Postfix) with ESMTP id 37BF728C0E8 for ; Thu, 8 Jan 2009 10:25:10 -0800 (PST) x-SBRS: None X-REMOTE-IP: 156.80.7.152 X-IronPort-AV: E=Sophos;i="4.37,235,1231131600"; d="scan'208";a="32914431" Received: from bahmail.bah.com (HELO mclnexbh02.resource.ds.bah.com) ([156.80.7.152]) by mclniron02-int.bah.com with ESMTP; 08 Jan 2009 13:24:56 -0500 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.121]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 13:24:56 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 13:24:55 -0500 Message-ID: <06BB54A6A9170048BC6BF56B88761E4B04348F95@MCLNEXVS05.resource.ds.bah.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate Thread-Index: AclxveBw/7ZdRdE1Q3GG1k4EUyHzVQAAFALQ From: "Kolenko, Marc [USA]" To: "Paul Hoffman" , , , , X-OriginalArrivalTime: 08 Jan 2009 18:24:56.0586 (UTC) FILETIME=[6863B6A0:01C971BE] Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Thank you for that guidance Paul. Well said. Marc Marc M. Kolenko, CISSP Information Assurance Manager ATAC Mission Support -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Thursday, January 08, 2009 1:21 PM To: cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate Folks: is rehashing the blue-sky discussions of how to create a better trust model for SSL without a stable proposal to look at really a good use of the the CFRG, SAAG, S/MIME, and PKIX mailing lists? If you want to be serious about this, please write an Internet Draft and set up a mailing list for the discussion. Invite people from these lists to join, and maybe announce revisions to your draft. Be sure to invite people from the Mozilla security community: they are having their own (perpetually repeating) discussion of this, again without a stable document to comment on. We *can* change the security model, but not with the current method of discussion-without-focus. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Jan 8 18:28:05 2009 Return-Path: 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 E311B3A68C1; Thu, 8 Jan 2009 18:28:05 -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 EA2BB3A68D5 for ; Thu, 8 Jan 2009 18:28:04 -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 9VO-eG34X0Gh for ; Thu, 8 Jan 2009 18:28:04 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 1EE203A68C1 for ; Thu, 8 Jan 2009 18:28:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E119D480B69; Fri, 9 Jan 2009 15:27:47 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQwQOQG9i2MP; Fri, 9 Jan 2009 15:27:47 +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 103DF480A1A; Fri, 9 Jan 2009 15:27:37 +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 83FDB1AE4003; Fri, 9 Jan 2009 15:27:35 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LL75z-0005wf-CT; Fri, 09 Jan 2009 15:27:35 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: eric.gray@ericsson.com, pgut001@cs.auckland.ac.nz, tytso@mit.edu In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0468D33B@eusrcmw721.eamcs.ericsson.se> Message-Id: Date: Fri, 09 Jan 2009 15:27:35 +1300 Cc: v.paz@uq.edu.au, cfrg@irtf.org, tmiller@mitre.org, saag@ietf.org, ietf-pkix@imc.org, ietf-smime@imc.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 "Eric Gray" writes: >Since the consumer ultimately pays the price in any case, perhaps a good >argument can be made for paying a portion of it up front? And how are you going to convince the consumer of this? They get "free" protection currently with their credit cards, and now they have to pay for it? (In fact there's already been a case of this failing in the past, when banks asked customers to pay a little extra to get their photos put on their credit cards for fraud protection. Went down like a lead zeppelin). Anything that involves customers having to pay for something that they consider as a right to get for free is going to fail before it even starts. That's actually not as bad as it sounds since it's one of the few hard-and- fast design guidelines for this area, unlike most other things ("this may or may not work, depending on the circumstances"). Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Feb 2 06:16:44 2009 Return-Path: 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 7897428C22C; Mon, 2 Feb 2009 06:16: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 5C8AA3A677E; Mon, 2 Feb 2009 06:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 USFs-KIWt3aw; Mon, 2 Feb 2009 06:16:35 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4B3613A6A0C; Mon, 2 Feb 2009 06:16:32 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n12EFmsW004210; Mon, 2 Feb 2009 16:16:10 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 16:16:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 16:16:04 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 2 Feb 2009 15:16:03 +0100 From: To: , Date: Mon, 2 Feb 2009 15:16:02 +0100 Thread-Topic: Pasi's AD Notes for January 2009 Thread-Index: AcmFQMb+KMeFp4+/R2e3EcHeSieBfw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78782E1@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2009 14:16:04.0568 (UTC) FILETIME=[C88A5580:01C98540] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for January 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi all, Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Security area WG chairs had a virtual meeting on January 12 to discuss having "virtual interim meetings" to help WGs get more work done between the IETF meetings. - (not wearing AD hat): Errata #1623 (for RFC 4282): waiting for Dan Romascanu to mark this as "Rejected" with note explaining why WORKING GROUPS DKIM - Lot of discussion about draft-ietf-dkim-rfc4871-errata and the meaning of d=/i= tags (and I haven't read all the emails). - draft-ietf-dkim-ssp: the errata discussion may impact Section 2.7 (or at least the reasoning behind doing it, even if no technical change is done), so currently I'm waiting to see if some kind of consensus is reached before taking ADSP to IESG. - draft-ietf-dkim-overview: in Publication Requested, waiting for ADSP to progress first (but since ADSP is taking longer than expected, I may attempt progressing them in parallel). - Waiting for WG to send list of RFC errata IDs the WG agrees on. EMU - draft-ietf-emu-gpsk: now in RFC Editor Queue/AUTH48 - Discussion about use of EAP type codes in EAP-FAST documents - Verified errata 1389 for EAP-TLS (RFC 5216) IPSECME - Busy month in IPSECME -- and lots of emails that I haven't read yet - Russ verified errata #1502 for RFC 4718 (IKEv2 Clarifications). ISMS - Lots of emails that I haven't read yet. KEYPROV - Lots of emails that I haven't read yet. PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: in RFC Editor Queue/AUTH48 - draft-ietf-pkix-rfc4055-update: went through IETF Last Call and IESG evaluation; waiting for the authors to propose text to handle Jari's discuss [since 2009-01-30] SASL - Some progress on SCRAM, it seems. SYSLOG - draft-ietf-syslog-transport-tls: now in RFC Editor Queue/AUTH48 state, but blocked by the RFC 5378 problem. - draft-ietf-syslog-sign: in AD Evaluation, waiting for me to read version -24 [since 2008-12-11] TLS - draft-ietf-tls-des-idea: now in RFC Editor Queue/AUTH48, waiting for me to check it [since 2009-01-30] - draft-ietf-tls-ecdhe-psk: went through IETF Last Call and IESG Evaluation; waiting to see if anyone in WG objects to text proposed to address Tim's discuss [since 2009-01-30]. - draft-ietf-tls-psk-new-mac-aes-gcm: was approved by IESG, going to RFC Editor Queue soon - draft-housley-tls-authz-extns went to 4th IETF Last Call - Errata #1585: waiting for Ekr to confirm that this errata is correct [since 2008-11-06] OTHER DOCUMENTS - draft-randall-3447bis: I finally reviewed this draft, and sent James Randall a bunch of comments. - draft-lebovitz-kmart-roadmap: now that -00 was posted, I have promised to comment and contribute. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. - draft-mattsson-srtp-store-and-forward: I've been planning to read this and send comments, but it seems unlikely I'll get to this anytime soon. DISCUSSES (active -- something happened within last month) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-ietf-l2tpext-tdm: waiting for the authors or Mark to reply [since 2009-01-27] - draft-ietf-mext-nemo-v4traversal: discussion ongoing, waiting for authors to propose text [since 2009-01-19] - draft-ietf-mipshop-mstp-solution: waiting for Jari to confirm that the proposed IESG note is OK; will move to "Abstain" once Jari says we're ready to go [since 2009-01-30] - draft-ietf-monami6-multiplecoa: some text agreed, waiting for authors to reply to my remaining comments [since 2009-01-28] - draft-ietf-nfsv4-rfc1831bis: I need to check if version -11 addresses my comments [since 2009-01-30] - draft-ietf-ospf-lls: waiting for a revised ID or RFC Editor Notes to address my remaining comments [since 2009-01-19] - draft-ietf-radext-management-authorization: waiting for authors to reply to my comments [since 2009-01-28] - draft-ietf-roll-urban-routing-reqs: good discussion ongoing, waiting for the authors to reply [since 2009-01-27] - draft-ietf-shim6-proto: discussion ongoing, waiting for me to review the text proposed by Erik [since 2009-01-24] - draft-ietf-softwire-encaps-ipsec: lots of emails that I need to read [since 2009-01-29] - draft-ietf-softwire-encaps-safi: waiting for Dave/Ross to check the text proposed by authors [since 2009-02-02] - draft-ietf-softwire-hs-framework-l2tpv2: discussion ongoing, waiting for authors to reply or submit a revised ID [since 2009-01-30] - draft-igoe-secsh-aes-gcm: authors have proposed text to partially address my discuss; waiting for Tim to take a look and comment [2009-01-30] - draft-kato-camellia-ctrccm: authors have proposed text that would resolve my comments; waiting for a revised ID [since 2009-01-06] - draft-stjohns-sipso: waiting for Tim to propose a path forward [since 2009-01-29] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-calsify-rfc2445bis: waiting for authors to reply to my comment [since 2008-12-18] - draft-ietf-enum-combined: waiting for authors to propose text or a revised ID [since 2008-12-11] - draft-ietf-sip-dtls-srtp-framework: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] - draft-kato-ipsec-camellia-modes: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] --end-- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From tim.polk@nist.gov Fri Feb 20 09:56:16 2009 Return-Path: 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 137DD3A6B11 for ; Fri, 20 Feb 2009 09:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 P+eDXd876Zs8 for ; Fri, 20 Feb 2009 09:56:14 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 93D0A3A6BB3 for ; Fri, 20 Feb 2009 09:56:14 -0800 (PST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n1KHuL65019774; Fri, 20 Feb 2009 12:56:22 -0500 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Fri, 20 Feb 2009 12:56:20 -0500 To: saag@ietf.org X-Mailer: Apple Mail (2.753.1) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:56:16 -0000 Folks, Pasi and I are working on the agenda for saag at IETF 74. We would appreciate any suggestions! Thanks, Tim Polk From pbaker@verisign.com Fri Feb 20 11:06:20 2009 Return-Path: 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 654F43A6840 for ; Fri, 20 Feb 2009 11:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 lxwEE6Ar1gwD for ; Fri, 20 Feb 2009 11:06:19 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 7E8C93A68FE for ; Fri, 20 Feb 2009 11:06:19 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1KIgNCX004140; Fri, 20 Feb 2009 10:42:26 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 11:06:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9938E.5743793A" Date: Fri, 20 Feb 2009 11:06:31 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2B8@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Request for agenda items Thread-Index: AcmThJQh6jLmDCskRvyZQLvSxZYXKwACKyB1 References: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> From: "Hallam-Baker, Phillip" To: "Tim Polk" , X-OriginalArrivalTime: 20 Feb 2009 19:06:32.0053 (UTC) FILETIME=[57910250:01C9938E] Subject: Re: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:06:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9938E.5743793A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Should probably raise awareness of the fact that the SHA1-to SHA-n = algorithm transition is not going to look anything like the MD5-SHA1 = transition. =20 The MD5 to SHA1 transition was relatively painless because almost every = cryptographic protocol that supported one also supported the other. In = the mid 1990s the fashion was to have redundant algorithms and MD5 and = SHA1 came out round about the same time. In particular every browser = that supported SSL 2.0 was required to support both. =20 The transition away from SHA1 is going to be a bear. It is going to be = very difficult to do without turning off security in a lot of legacy = browsers. Note here that I say 'turn off security' and not 'turn off the = browsers'. We need to work out a pragmatic transition strategy that = delivers the maximum security for the maximum number of people over the = maximum amount of time. =20 If we start addressing the problem now we can lay ourselves an insurance = policy. If we try to insist on the pristine principles of the PKIX = infrastructure we are going to be in deep trouble in about five years = time. =20 This problem is particularly bad because there is an increasing use of = SSL in embedded devices that are designed with ten to twenty year = service lives and have no firmware upgrade plan. =20 ________________________________ From: saag-bounces@ietf.org on behalf of Tim Polk Sent: Fri 2/20/2009 12:56 PM To: saag@ietf.org Subject: [saag] Request for agenda items Folks, Pasi and I are working on the agenda for saag at IETF 74. We would=20 appreciate any suggestions! Thanks, Tim Polk _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C9938E.5743793A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [saag] Request for agenda items=0A= =0A= =0A= =0A=
=0A=
Should = probably raise awareness of the fact that the SHA1-to SHA-n algorithm = transition is not going to look anything like the MD5-SHA1 = transition.
=0A=
 
=0A=
The MD5 to SHA1 transition = was relatively painless because almost every cryptographic protocol that = supported one also supported the other. In the mid 1990s the fashion was = to have redundant algorithms and MD5 and SHA1 came out round about the = same time. In particular every browser that supported SSL 2.0 was = required to support both.
=0A=
 
=0A=
The transition away from SHA1 = is going to be a bear. It is going to be very difficult to do without = turning off security in a lot of legacy browsers. Note here that I say = 'turn off security' and not 'turn off the browsers'. We need to work out = a pragmatic transition strategy that delivers the maximum security for = the maximum number of people over the maximum amount of = time.
=0A=
 
=0A=
If we start addressing the = problem now we can lay ourselves an insurance policy. If we try to = insist on the pristine principles of the PKIX infrastructure we are = going to be in deep trouble in about five years time.
=0A=
 
=0A=
This problem is particularly = bad because there is an increasing use of SSL in embedded devices that = are designed with ten to twenty year service lives and have no firmware = upgrade plan.
=0A=
 
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Tim Polk
Sent: Fri 2/20/2009 12:56 PM
To: = saag@ietf.org
Subject: [saag] Request for agenda = items

=0A=
=0A=

Folks,

Pasi and I are working on the agenda for = saag at IETF 74.  We would 
appreciate any = suggestions!

Thanks,

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

------_=_NextPart_001_01C9938E.5743793A-- From kent@bbn.com Sat Feb 21 08:10:08 2009 Return-Path: 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 301D93A685C for ; Sat, 21 Feb 2009 08:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 TFnLi1OLbTMc for ; Sat, 21 Feb 2009 08:10:07 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0CD333A68CC for ; Sat, 21 Feb 2009 08:10:07 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.22.91]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LauQk-0005m3-DN; Sat, 21 Feb 2009 11:10:18 -0500 Mime-Version: 1.0 Message-Id: Date: Sat, 21 Feb 2009 11:10:03 -0500 To: saag@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-976889879==_ma============" Subject: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 16:10:08 -0000 --============_-976889879==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I agree wit Phil's suggestion that we begin work on this topic sooner rather than later. Solutions probably will require coordination between folks in both PKIX and TLS, plus some browser experts from the APP area. However, Phil's comment (underling added by me) If we start addressing the problem now we can lay ourselves an insurance policy. If we try to insist on the pristine principles of the PKIX infrastructure we are going to be in deep trouble in about five years time. is offensive, at best. Moreover, unless Phil and his favorite browser vendors already have a solution in mind, and he anticipates that it will be objectionable to PKIX, this comment is gratuitous. Since we're talking about how well browsers implement PKI mechanisms in the context of SSL/TLS, it is worth noting a presentation at last week's Black Hat conference in D.C. The presentation provided details on how several browsers remain vulnerable to attacks because they fails to check the Basic Constraints extension. This oversight of one of those pristine principles of PKIX ( we can use the acronym P3 going forward) and allows a web sites to act as a CA, based o the EE cert issued to it by any of the trust anchors embedded in the browser. Another vulnerability, and matching MITM attack, is enabled by the issuance of certs that contain wildcard DNS names. This is not, a violation of P3, because PKIX caved to pressure from the TLS WG, to accommodate web site operators who wanted to purchase one cert from a TTP that could be used to verify the EE certs for multiple web sites. I argued against this, but lost. The phrase "I told you so" comes to mind :-). So, contrary to Phil's assertion that adherence to P3 will get us into deep trouble in five years (with regard to this transition issue), I believe that PKI shortcuts (hacks) in browsers have gotten us into deep trouble for many years, and are likely to persist. Steve --============_-976889879==_ma============ Content-Type: text/html; charset="us-ascii" SHA-1 to SHA-n transition
I agree wit Phil's suggestion that we begin work on this topic sooner rather than later.  Solutions probably will require coordination between folks in both PKIX and TLS, plus some browser experts from the APP area.

However, Phil's comment (underling added by me)

If we start addressing the problem now we can lay ourselves an insurance policy. If we try to insist on the pristine principles of the PKIX infrastructure we are going to be in deep trouble in about five years time.

is offensive, at best. Moreover, unless Phil and his favorite browser vendors already have a solution in mind, and he anticipates that it will be objectionable to PKIX, this comment is gratuitous.

Since we're talking about how well browsers implement PKI mechanisms in the context of SSL/TLS, it is worth noting a presentation at last week's Black Hat conference in D.C. The presentation provided details on how several browsers remain vulnerable to attacks because they fails to check the Basic Constraints extension. This oversight of one of those pristine principles of PKIX ( we can use the acronym P3 going forward) and allows a web sites to act as a CA, based o the EE cert issued to it by any of the trust anchors embedded in the browser.

Another vulnerability, and matching MITM attack, is enabled by the issuance of certs that contain wildcard DNS names. This is not, a violation of P3, because PKIX caved to pressure from the TLS WG, to accommodate web site operators who wanted to purchase one cert from a TTP that could be used to verify the EE certs for multiple web sites. I argued against this, but lost. The phrase "I told you so" comes to mind :-).

So, contrary to Phil's assertion that adherence to P3 will get us into deep trouble in five years (with regard to this transition issue), I believe that PKI shortcuts (hacks) in browsers have gotten us into deep trouble for many years, and are likely to persist.

Steve
--============_-976889879==_ma============-- From fernando@gont.com.ar Sat Feb 21 15:44:46 2009 Return-Path: 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 6BA903A677D for ; Sat, 21 Feb 2009 15:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 iKXvQS1qpaq3 for ; Sat, 21 Feb 2009 15:44:45 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5376A3A6816 for ; Sat, 21 Feb 2009 15:44:44 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 282FD6B6573 for ; Sat, 21 Feb 2009 20:45:05 -0300 (ART) Received: from [192.168.0.106] (131-131-17-190.fibertel.com.ar [190.17.131.131]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n1LNijbE012955; Sat, 21 Feb 2009 21:44:46 -0200 Message-ID: <49A091F4.4010801@gont.com.ar> Date: Sat, 21 Feb 2009 21:44:52 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 21 Feb 2009 20:45:04 -0300 (ART) Subject: [saag] Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:44:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, Last week the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure) released the document "Security Assessment of the Transmission Control Protocol (TCP)". The document analyzes the relevant specifications from a security point of view, and also analyzes the implications of some implementation strategies taken by popular TCP implementations. This document is available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf As part of the same project, we have produced an IETF I-D version of the UK CPNI document, in the hope that the IETF works on this stuff and hopefully publishes some version of the aforementioned document. The resulting IETF I-D is entitled "Security Assessment of the Transmission Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt Any comments will be more than welcome. Thanks! Kind regards, - -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJJoJHoAAoJEJbuqe/Qdv/xZLwH/iUg1q80GjILHbrjiXsF1kHf kDCtn1AP2fAV5h2VHoVTTOa5OW0S8SoAHck9aqpsP4MIqeY+e8JTN7B4hg8NgSE4 HLIDN4e+uuoZHCqbbB8UHgPHDRwsjTTcHlqMB6msM+aSG5INF4Ng34cS65CGJBsS IdsCsxgUEFfYkrRLFSG6b7gaap6TDSrvczvO0pPLfCzL8lyUy1+4LaLyUrU+TiGZ thSxF6g//Z5MDg6McBZfMaQThg/It4iWzLgInPWLcJlljv5HcloDxjEqnlFuHU9v dm+ZourMytQJ0wLcSLWMWX6Ige9DJ+KitKLdRrYRVBZVdWWPIVXI7HXR9HcEgiM= =z5kP -----END PGP SIGNATURE----- From ekr@networkresonance.com Sat Feb 21 17:44:07 2009 Return-Path: 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 10F933A6A79 for ; Sat, 21 Feb 2009 17:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] 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 wuOSALqJpvtB for ; Sat, 21 Feb 2009 17:44:06 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 468FD3A67B2 for ; Sat, 21 Feb 2009 17:44:06 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8621A50822; Sat, 21 Feb 2009 18:07:09 -0800 (PST) Date: Sat, 21 Feb 2009 18:07:09 -0800 From: Eric Rescorla To: Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090222020709.8621A50822@romeo.rtfm.com> Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:44:07 -0000 At Sat, 21 Feb 2009 11:10:03 -0500, Stephen Kent wrote: > I agree wit Phil's suggestion that we begin work on this topic sooner > rather than later. Solutions probably will require coordination > between folks in both PKIX and TLS, plus some browser experts from > the APP area. I should note that TLS 1.2 already has support for SHA-n, as well as mechanisms for indicating that an implementation will accept these certificates. Deployment of 1.2 has been minimal so far, but I'm not aware of any new protocol design work that needs to be done here. > Since we're talking about how well browsers implement PKI mechanisms > in the context of SSL/TLS, it is worth noting a presentation at last > week's Black Hat conference in D.C. The presentation provided details > on how several browsers remain vulnerable to attacks because they > fails to check the Basic Constraints extension. This oversight of one > of those pristine principles of PKIX ( we can use the acronym P3 > going forward) and allows a web sites to act as a CA, based o the EE > cert issued to it by any of the trust anchors embedded in the browser. I agree that this is a problem. > Another vulnerability, and matching MITM attack, is enabled by the > issuance of certs that contain wildcard DNS names. This is not, a > violation of P3, because PKIX caved to pressure from the TLS WG, to > accommodate web site operators who wanted to purchase one cert from a > TTP that could be used to verify the EE certs for multiple web sites. > I argued against this, but lost. The phrase "I told you so" comes to > mind :-). Can you briefly describe how this leads to MITM attacks? This is something I haven't heard before. Best, -Ekr From Hannes.Tschofenig@gmx.net Sun Feb 22 01:57:02 2009 Return-Path: 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 F0A353A697E for ; Sun, 22 Feb 2009 01:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 c7dw851QTbPt for ; Sun, 22 Feb 2009 01:57:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6DCD23A682D for ; Sun, 22 Feb 2009 01:57:00 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2009 09:57:15 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 22 Feb 2009 10:57:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Wswsf1ieW47sdDcZXX9rr25g11pYq7Or8JwW04P JmqiDayZQ9EvtF From: "Hannes Tschofenig" To: "'Eric Rescorla'" , "'Stephen Kent'" References: <20090222020709.8621A50822@romeo.rtfm.com> Date: Sun, 22 Feb 2009 11:58:11 +0200 Message-ID: <026501c994d4$13691080$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <20090222020709.8621A50822@romeo.rtfm.com> Thread-Index: AcmUjxiOM7Mw1vSGSXqFLDSYdpoXOwAQrrEA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 09:57:03 -0000 Hi Ekr, Stephen is referring to the nice presenation at the Black Hat conference, see http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Ma rlinspike-Defeating-SSL.pdf I don't think that there is anything new in there but the slide set provides a nice sate-of-the-art summary and points to the importance of properly designed user interfaces. On the latter issue I have also noticed that in the IETF we used to say that user-interface aspects are outside the scope of our work. This leads to totally ignoring the way how the user utilizes the protocols we develop (even though I understand that we don't want to standardize a particular interface itself). However, for the complete solution the user experience is something really important. My recent examples were user interface aspect matter are: authorization policies we use in the SIP environment, SIP Identity/SIP Security, early warning messages, all sorts of identity management solutions (although they are mostly developed outside the IETF). Ciao Hannes >-----Original Message----- >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >Behalf Of Eric Rescorla >Sent: 22 February, 2009 04:07 >To: Stephen Kent >Cc: saag@ietf.org >Subject: Re: [saag] SHA-1 to SHA-n transition > >At Sat, 21 Feb 2009 11:10:03 -0500, >Stephen Kent wrote: >> I agree wit Phil's suggestion that we begin work on this >topic sooner >> rather than later. Solutions probably will require coordination >> between folks in both PKIX and TLS, plus some browser >experts from the >> APP area. > >I should note that TLS 1.2 already has support for SHA-n, as >well as mechanisms for indicating that an implementation will >accept these certificates. Deployment of 1.2 has been minimal >so far, but I'm not aware of any new protocol design work that >needs to be done here. > >> Since we're talking about how well browsers implement PKI mechanisms >> in the context of SSL/TLS, it is worth noting a presentation at last >> week's Black Hat conference in D.C. The presentation >provided details >> on how several browsers remain vulnerable to attacks because they >> fails to check the Basic Constraints extension. This >oversight of one >> of those pristine principles of PKIX ( we can use the >acronym P3 going >> forward) and allows a web sites to act as a CA, based o the EE cert >> issued to it by any of the trust anchors embedded in the browser. > >I agree that this is a problem. > > >> Another vulnerability, and matching MITM attack, is enabled by the >> issuance of certs that contain wildcard DNS names. This is not, a >> violation of P3, because PKIX caved to pressure from the TLS WG, to >> accommodate web site operators who wanted to purchase one >cert from a >> TTP that could be used to verify the EE certs for multiple web sites. >> I argued against this, but lost. The phrase "I told you so" comes to >> mind :-). > >Can you briefly describe how this leads to MITM attacks? This >is something I haven't heard before. > >Best, >-Ekr >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag > From kent@bbn.com Sun Feb 22 17:57:18 2009 Return-Path: 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 9633A3A6844 for ; Sun, 22 Feb 2009 17:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 R3Ci4x841bEf for ; Sun, 22 Feb 2009 17:57:17 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C776C3A67A8 for ; Sun, 22 Feb 2009 17:57:17 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.35.46]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LbQ4b-0003h4-BY; Sun, 22 Feb 2009 20:57:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090222020709.8621A50822@romeo.rtfm.com> References: <20090222020709.8621A50822@romeo.rtfm.com> Date: Sun, 22 Feb 2009 20:53:04 -0500 To: Eric Rescorla From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:57:18 -0000 At >... >> Another vulnerability, and matching MITM attack, is enabled by the >> issuance of certs that contain wildcard DNS names. This is not, a >> violation of P3, because PKIX caved to pressure from the TLS WG, to >> accommodate web site operators who wanted to purchase one cert from a >> TTP that could be used to verify the EE certs for multiple web sites. >> I argued against this, but lost. The phrase "I told you so" comes to >> mind :-). > >Can you briefly describe how this leads to MITM attacks? This is something >I haven't heard before. Look at the latter half of these slides for his description of the role that wildcard DNS names on certs play in one class of attacks. Steve From cchander@ida.org Mon Feb 23 09:11:03 2009 Return-Path: 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 F0A763A698F for ; Mon, 23 Feb 2009 09:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 yqnYcDZsp09d for ; Mon, 23 Feb 2009 09:11:02 -0800 (PST) Received: from exim1-out.ida.org (exim1-out.ida.org [129.246.101.13]) by core3.amsl.com (Postfix) with ESMTP id B2FD13A6874 for ; Mon, 23 Feb 2009 09:11:02 -0800 (PST) Received: by exim1-out.ida.org with local-smtp for ; Mon, 23 Feb 2009 12:11:15 -0500 Received: by exim1-out.ida.org with esmtp ; Mon, 23 Feb 2009 12:11:15 -0500 Received: from exch07-hc2.ida.org ([129.246.101.156]) by ex2kmail.ida.org with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 12:10:13 -0500 Received: from EXCH07-4850.ida.org ([129.246.101.159]) by exch07-hc2.ida.org ([129.246.101.156]) with mapi; Mon, 23 Feb 2009 12:10:13 -0500 From: "Chandersekaran, Coimbatore S" To: Hannes Tschofenig , 'Eric Rescorla' , 'Stephen Kent' Date: Mon, 23 Feb 2009 12:08:56 -0500 Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmUjxiOM7Mw1vSGSXqFLDSYdpoXOwAQrrEAAEHlhCQ= Message-ID: <9F8E44BC27E22046B84EC1B9364C66A181CD725935@EXCH07-4850.ida.org> References: <20090222020709.8621A50822@romeo.rtfm.com>, <026501c994d4$13691080$0201a8c0@nsnintra.net> In-Reply-To: <026501c994d4$13691080$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2009 17:10:13.0349 (UTC) FILETIME=[972C8950:01C995D9] Cc: "saag@ietf.org" Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:11:04 -0000 Cannot connect to the site. Get a 404 error. Can someone post this deck to= SAAG?=20 ________________________________________ From: saag-bounces@ietf.org [saag-bounces@ietf.org] On Behalf Of Hannes Tsc= hofenig [Hannes.Tschofenig@gmx.net] Sent: Sunday, February 22, 2009 4:58 AM To: 'Eric Rescorla'; 'Stephen Kent' Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition Hi Ekr, Stephen is referring to the nice presenation at the Black Hat conference, see http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-M= a rlinspike-Defeating-SSL.pdf I don't think that there is anything new in there but the slide set provide= s a nice sate-of-the-art summary and points to the importance of properly designed user interfaces. On the latter issue I have also noticed that in the IETF we used to say that user-interface aspects are outside the scope o= f our work. This leads to totally ignoring the way how the user utilizes the protocols we develop (even though I understand that we don't want to standardize a particular interface itself). However, for the complete solution the user experience is something really important. My recent examples were user interface aspect matter are: authorization policies we use in the SIP environment, SIP Identity/SIP Security, early warning messages, all sorts of identity management solutions (although they are mostly developed outside the IETF). Ciao Hannes >-----Original Message----- >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >Behalf Of Eric Rescorla >Sent: 22 February, 2009 04:07 >To: Stephen Kent >Cc: saag@ietf.org >Subject: Re: [saag] SHA-1 to SHA-n transition > >At Sat, 21 Feb 2009 11:10:03 -0500, >Stephen Kent wrote: >> I agree wit Phil's suggestion that we begin work on this >topic sooner >> rather than later. Solutions probably will require coordination >> between folks in both PKIX and TLS, plus some browser >experts from the >> APP area. > >I should note that TLS 1.2 already has support for SHA-n, as >well as mechanisms for indicating that an implementation will >accept these certificates. Deployment of 1.2 has been minimal >so far, but I'm not aware of any new protocol design work that >needs to be done here. > >> Since we're talking about how well browsers implement PKI mechanisms >> in the context of SSL/TLS, it is worth noting a presentation at last >> week's Black Hat conference in D.C. The presentation >provided details >> on how several browsers remain vulnerable to attacks because they >> fails to check the Basic Constraints extension. This >oversight of one >> of those pristine principles of PKIX ( we can use the >acronym P3 going >> forward) and allows a web sites to act as a CA, based o the EE cert >> issued to it by any of the trust anchors embedded in the browser. > >I agree that this is a problem. > > >> Another vulnerability, and matching MITM attack, is enabled by the >> issuance of certs that contain wildcard DNS names. This is not, a >> violation of P3, because PKIX caved to pressure from the TLS WG, to >> accommodate web site operators who wanted to purchase one >cert from a >> TTP that could be used to verify the EE certs for multiple web sites. >> I argued against this, but lost. The phrase "I told you so" comes to >> mind :-). > >Can you briefly describe how this leads to MITM attacks? This >is something I haven't heard before. > >Best, >-Ekr >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag= From ekr@networkresonance.com Mon Feb 23 09:40:12 2009 Return-Path: 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 14FA33A6AEF for ; Mon, 23 Feb 2009 09:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 KfpYqb8DR6ni for ; Mon, 23 Feb 2009 09:40:11 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 2B6793A684E for ; Mon, 23 Feb 2009 09:40:11 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 68AB850822; Mon, 23 Feb 2009 10:03:17 -0800 (PST) Date: Mon, 23 Feb 2009 10:03:17 -0800 From: Eric Rescorla To: Stephen Kent In-Reply-To: References: <20090222020709.8621A50822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090223180317.68AB850822@romeo.rtfm.com> Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:40:12 -0000 At Sun, 22 Feb 2009 20:53:04 -0500, Stephen Kent wrote: > > At > >... > >> Another vulnerability, and matching MITM attack, is enabled by the > >> issuance of certs that contain wildcard DNS names. This is not, a > >> violation of P3, because PKIX caved to pressure from the TLS WG, to > >> accommodate web site operators who wanted to purchase one cert from a > >> TTP that could be used to verify the EE certs for multiple web sites. > >> I argued against this, but lost. The phrase "I told you so" comes to > >> mind :-). > > > >Can you briefly describe how this leads to MITM attacks? This is something > >I haven't heard before. > > Look at the latter half of these slides for his description of the > role that wildcard DNS names on certs play in one class of attacks. > > This gets me a 404 as well. -Ekr From pbaker@verisign.com Mon Feb 23 10:40:22 2009 Return-Path: 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 59F2D3A68B0 for ; Mon, 23 Feb 2009 10:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=0.001] 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 XvhhCxBUfYzq for ; Mon, 23 Feb 2009 10:40:17 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 4F4C43A6872 for ; Mon, 23 Feb 2009 10:40:17 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1NIeOTa014113; Mon, 23 Feb 2009 10:40:24 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 10:40:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C995E6.2FDE36A2" Date: Mon, 23 Feb 2009 10:40:23 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2BC@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmV3dX8S70ll9ZGRXCl2Gt+Qpw/pwABftlM References: <20090222020709.8621A50822@romeo.rtfm.com> <20090223180317.68AB850822@romeo.rtfm.com> From: "Hallam-Baker, Phillip" To: "Eric Rescorla" , "Stephen Kent" X-OriginalArrivalTime: 23 Feb 2009 18:40:24.0767 (UTC) FILETIME=[30A164F0:01C995E6] Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:40:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C995E6.2FDE36A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The basic attack was to obtain a domain name in a zone that does not = have I18N homograph protection on by default (e.g. example.cn) then look = for a homograph character for / =20 Then set a domain name http://anysite.com/padding/.example.cn/ which = will bind to a wildcard. Where com/padding/ is actually a single DNS = label with two lookalikes for / in it. =20 The same thing is done today with = http://anysite.comlpaddingI.example.com/ =20 =20 However the presenter is not entirely correct in his claims =20 * The wildcard attack does not affect EV as claimed as wildcards are = prohibited in EV certs.=20 * Contrary to the presenter's claims, there is nothing that obligates = him to release exploit code * The presenter fails to mention that at least one of the sites he uses = as an example of a password submission form on an unprotected page has = not been configured that way for over two years, point of that example = seems to have been that he got himself on TV. * No mention at all of the W3C Web Security Context Working Group that = was set up to make recommendations on these UI issues and currently has = a document about to enter last call. =20 All in all, folk who are watching presentations on social engineering = exploits should always ask themselves who is being socially engineered = and for what purpose. =20 =20 ________________________________ From: saag-bounces@ietf.org on behalf of Eric Rescorla Sent: Mon 2/23/2009 1:03 PM To: Stephen Kent Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition At Sun, 22 Feb 2009 20:53:04 -0500, Stephen Kent wrote: > > At > >... > >> Another vulnerability, and matching MITM attack, is enabled by the > >> issuance of certs that contain wildcard DNS names. This is not, a > >> violation of P3, because PKIX caved to pressure from the TLS WG, = to > >> accommodate web site operators who wanted to purchase one cert = from a > >> TTP that could be used to verify the EE certs for multiple web = sites. > >> I argued against this, but lost. The phrase "I told you so" comes = to > >> mind :-). > > > >Can you briefly describe how this leads to MITM attacks? This is = something > >I haven't heard before. > > Look at the latter half of these slides for his description of the > role that wildcard DNS names on certs play in one class of attacks. > > = This gets me a 404 as well. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C995E6.2FDE36A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
The basic = attack was to obtain a domain name in a zone that does not have = I18N homograph protection on by default (e.g. example.cn) then look = for a homograph character for /
=0A=
 
=0A=
Then set a domain name http://anysite.com/paddi= ng/.example.cn/ which will bind to a wildcard. Where = com/padding/ is actually a single DNS label with two lookalikes for / in = it.
=0A=
 
=0A=
The same thing is done = today with http://anysite.comlpadd= ingI.example.com/
=0A=
 
=0A=
 
=0A=
However the presenter is not = entirely correct in his claims
=0A=
 
=0A=
* The wildcard attack does = not affect EV as claimed as wildcards are prohibited in EV certs. =
=0A=
* Contrary to the presenter's = claims, there is nothing that obligates him to release exploit = code
=0A=
* The presenter fails to = mention that at least one of the sites he uses as an example of a = password submission form on an unprotected page has not been configured = that way for over two years, point of that example seems to have been = that he got himself on TV.
=0A=
* No mention at all of the = W3C Web Security Context Working Group that was set up to make = recommendations on these UI issues and currently has a document about to = enter last call.
=0A=
 
=0A=
All in all, folk who are = watching presentations on social engineering exploits should always ask = themselves who is being socially engineered and for what = purpose.
=0A=
 
=0A=
 
=0A=
=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Eric Rescorla
Sent: Mon 2/23/2009 1:03 = PM
To: Stephen Kent
Cc: = saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=

At Sun, 22 Feb 2009 20:53:04 -0500,
Stephen Kent = wrote:
>
> At
> >...
> >>  Another = vulnerability, and matching MITM attack, is enabled by the
> = >>  issuance of certs that contain wildcard DNS names. This = is not, a
> >>  violation of P3, because PKIX caved to = pressure from the TLS WG, to
> >>  accommodate web site = operators who wanted to purchase one cert from a
> >>  = TTP that could be used to verify the EE certs for multiple web = sites.
> >>  I argued against this, but lost. The = phrase "I told you so" comes to
> >>  mind :-).
> = >
> >Can you briefly describe how this leads to MITM = attacks? This is something
> >I haven't heard = before.
>
> Look at the latter half of these slides for his = description of the
> role that wildcard DNS names on certs play in = one class of attacks.
>
> <https://www.blackhat.com/present= ations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<= /A>>

This gets me a 404 as = well.

-Ekr
_______________________________________________
s= aag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C995E6.2FDE36A2-- From pbaker@verisign.com Mon Feb 23 11:13:51 2009 Return-Path: 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 1E8E63A6962 for ; Mon, 23 Feb 2009 11:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 MVhWT2vmyBAX for ; Mon, 23 Feb 2009 11:13:49 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E50D43A6872 for ; Mon, 23 Feb 2009 11:13:49 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1NIneDq012889; Mon, 23 Feb 2009 10:49:40 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 11:13:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C995EA.DEF2445E" Date: Mon, 23 Feb 2009 11:13:55 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2BD@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmUPu2BuBpQlTXAQDetUEXQp8IetwBp3nWt References: From: "Hallam-Baker, Phillip" To: "Stephen Kent" , X-OriginalArrivalTime: 23 Feb 2009 19:13:56.0478 (UTC) FILETIME=[DFB421E0:01C995EA] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:13:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C995EA.DEF2445E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let us see, I suggest that we might need to slay a sacred PKIX cow or = two in order to make the SHA-n transition work. Stephen:=20 =20 * Describes the suggestion as 'offensive' * Raises a non sequitor about certificate issue policy =20 I canot imagine why Stephen would imagine that a sensible response to a = technical issue would be found in relaxing certificate issue policy = criteria, or for that matter why I would be likely to be suggesting = that.=20 =20 I did however anticipate that Stephen would find my proposal = objectionable. But was somewhat surprised that he didn't wait to find = out what it was before objecting. =20 =20 We have a problem here that requires us to work out a coherent = transition plan for enabling browsers to make use of the stronger = security of SHA2 and SHAn at the earliest possible date taking into = account that we have a very small installed base of SHA2 capable clients = and no spec for SHAn. =20 The problem is that you do not gain security from introducing stronger = algorithms, you only gain security from withdrawing insecure algorithms = from use. And for better or worse, there are real limits to what the = Internet user base will tollerate for security. =20 So simply adding SHA2 support to existing browsers does not help us much = unless we have a way to retrospectively shut off SHA1 support when it is = no longer trustworthy.=20 =20 And even that does not help very much as there will be a large number of = certificate customers who want to sell to people who can only use SHA1 = capable browsers. =20 And then we have the problem that PKIX does not really have a strategy = for algorithm transition. It has the ability to use multiple algorithms = but not very much thought of how the transition from one to another = takes place. =20 ________________________________ From: saag-bounces@ietf.org on behalf of Stephen Kent Sent: Sat 2/21/2009 11:10 AM To: saag@ietf.org Subject: [saag] SHA-1 to SHA-n transition I agree wit Phil's suggestion that we begin work on this topic sooner = rather than later. Solutions probably will require coordination between = folks in both PKIX and TLS, plus some browser experts from the APP area. However, Phil's comment (underling added by me) If we start addressing the problem now we can lay ourselves an insurance = policy. If we try to insist on the pristine principles of the PKIX = infrastructure we are going to be in deep trouble in about five years = time. is offensive, at best. Moreover, unless Phil and his favorite browser = vendors already have a solution in mind, and he anticipates that it will = be objectionable to PKIX, this comment is gratuitous. Since we're talking about how well browsers implement PKI mechanisms in = the context of SSL/TLS, it is worth noting a presentation at last week's = Black Hat conference in D.C. The presentation provided details on how = several browsers remain vulnerable to attacks because they fails to = check the Basic Constraints extension. This oversight of one of those = pristine principles of PKIX ( we can use the acronym P3 going forward) = and allows a web sites to act as a CA, based o the EE cert issued to it = by any of the trust anchors embedded in the browser. Another vulnerability, and matching MITM attack, is enabled by the = issuance of certs that contain wildcard DNS names. This is not, a = violation of P3, because PKIX caved to pressure from the TLS WG, to = accommodate web site operators who wanted to purchase one cert from a = TTP that could be used to verify the EE certs for multiple web sites. I = argued against this, but lost. The phrase "I told you so" comes to mind = :-). So, contrary to Phil's assertion that adherence to P3 will get us into = deep trouble in five years (with regard to this transition issue), I = believe that PKI shortcuts (hacks) in browsers have gotten us into deep = trouble for many years, and are likely to persist. Steve ------_=_NextPart_001_01C995EA.DEF2445E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SHA-1 to SHA-n transition=0A= =0A= =0A= =0A= =0A= =0A=
Let us see, I suggest that we = might need to slay a sacred PKIX cow or two in order to make the SHA-n = transition work. Stephen:
=0A=
 
=0A=
* Describes the suggestion as 'offensive'
=0A=
* Raises a non sequitor about certificate issue = policy
=0A=
 
=0A=
I canot imagine why Stephen would imagine that a sensible = response to a technical issue would be found in relaxing certificate = issue policy criteria, or for that matter why I would be likely to be = suggesting that.
=0A=
 
=0A=
I did however anticipate that Stephen would find my = proposal objectionable. But was somewhat surprised that he didn't wait = to find out what it was before objecting.
=0A=
 
=0A=
 
=0A=
We have a problem here that requires us to work out a = coherent transition plan for enabling browsers to make use of the = stronger security of SHA2 and SHAn at the earliest possible date taking = into account that we have a very small installed base of SHA2 capable = clients and no spec for SHAn.
=0A=
 
=0A=
The problem is that you do not gain security from = introducing stronger algorithms, you only gain security from withdrawing = insecure algorithms from use. And for better or worse, there are real = limits to what the Internet user base will tollerate for = security.
=0A=
 
=0A=
So simply adding SHA2 support to existing browsers does = not help us much unless we have a way to retrospectively shut off SHA1 = support when it is no longer trustworthy.
=0A=
 
=0A=
And even that does not help very much as there will be a = large number of certificate customers who want to sell to people who can = only use SHA1 capable browsers.
=0A=
 
=0A=
And then we have the problem that PKIX does not really = have a strategy for algorithm transition. It has the ability to use = multiple algorithms but not very much thought of how the transition from = one to another takes place.
=0A=
 
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Stephen Kent
Sent: Sat 2/21/2009 11:10 = AM
To: saag@ietf.org
Subject: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=
I agree wit Phil's suggestion that we begin work on this topic = sooner rather than later.  Solutions probably will require = coordination between folks in both PKIX and TLS, plus some browser = experts from the APP area.
=0A=

=0A=
However, Phil's comment (underling added by me)
=0A=

=0A=
If we start addressing the problem now = we can lay ourselves an insurance policy. If we try to insist on the = pristine principles of the PKIX infrastructure we are going to be in = deep trouble in about five years time.
=0A=

=0A=
is offensive, at best. Moreover, unless Phil and his favorite = browser vendors already have a solution in mind, and he anticipates that = it will be objectionable to PKIX, this comment is gratuitous.
=0A=

=0A=
Since we're talking about how well browsers implement PKI = mechanisms in the context of SSL/TLS, it is worth noting a presentation = at last week's Black Hat conference in D.C. The presentation provided = details on how several browsers remain vulnerable to attacks because = they fails to check the Basic Constraints extension. This oversight of = one of those pristine principles of PKIX ( we can use the acronym P3 = going forward) and allows a web sites to act as a CA, based o the EE = cert issued to it by any of the trust anchors embedded in the = browser.
=0A=

=0A=
Another vulnerability, and matching MITM attack, is enabled by the = issuance of certs that contain wildcard DNS names. This is not, a = violation of P3, because PKIX caved to pressure from the TLS WG, to = accommodate web site operators who wanted to purchase one cert from a = TTP that could be used to verify the EE certs for multiple web sites. I = argued against this, but lost. The phrase "I told you so" comes to mind = :-).
=0A=

=0A=
So, contrary to Phil's assertion that adherence to P3 will get us = into deep trouble in five years (with regard to this transition issue), = I believe that PKI shortcuts (hacks) in browsers have gotten us into = deep trouble for many years, and are likely to persist.
=0A=

=0A=
Steve
------_=_NextPart_001_01C995EA.DEF2445E-- From ynir@checkpoint.com Mon Feb 23 12:08:57 2009 Return-Path: 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 3A15F3A6A05 for ; Mon, 23 Feb 2009 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 VuQJDNG9EgOv for ; Mon, 23 Feb 2009 12:08:56 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E0D813A67DD for ; Mon, 23 Feb 2009 12:08:53 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 558C52AC002; Mon, 23 Feb 2009 22:09:11 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 520162AC001; Mon, 23 Feb 2009 22:09:10 +0200 (IST) X-CheckPoint: {49A3019A-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1NK99sZ012394; Mon, 23 Feb 2009 22:09:09 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 23 Feb 2009 22:09:09 +0200 From: Yoav Nir To: Eric Rescorla Date: Mon, 23 Feb 2009 22:08:22 +0200 Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmV3dVtyy30CNRoRgSlkPTyTWoVzQAFKSqp Message-ID: <9FB7C7CE79B84449B52622B506C78036133291CB4A@il-ex01.ad.checkpoint.com> References: <20090222020709.8621A50822@romeo.rtfm.com> , <20090223180317.68AB850822@romeo.rtfm.com> In-Reply-To: <20090223180317.68AB850822@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:08:57 -0000 Does this help? http://tinyurl.com/d4gons ________________________________________ > > Look at the latter half of these slides for his description of the > role that wildcard DNS names on certs play in one class of attacks. > > This gets me a 404 as well. -Ekr Email secured by Check Point From Pasi.Eronen@nokia.com Tue Feb 24 03:49:10 2009 Return-Path: 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 7BF693A682A for ; Tue, 24 Feb 2009 03:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Sn+5KKJZjhjp for ; Tue, 24 Feb 2009 03:49:09 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 59E763A69F3 for ; Tue, 24 Feb 2009 03:49:07 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1OBnKwL027376; Tue, 24 Feb 2009 13:49:24 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 13:49:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 13:48:55 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 24 Feb 2009 12:48:55 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Tue, 24 Feb 2009 12:48:54 +0100 From: To: , Date: Tue, 24 Feb 2009 12:48:53 +0100 Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmUPu2BuBpQlTXAQDetUEXQp8IetwBp3nWtACN79IA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7B494E9@NOK-EUMSG-01.mgdnok.nokia.com> References: <2788466ED3E31C418E9ACC5C3166155768B2BD@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2BD@mou1wnexmb09.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB7727E7B494E9NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2009 11:48:55.0714 (UTC) FILETIME=[DF38A020:01C99675] X-Nokia-AV: Clean Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 11:49:10 -0000 --_000_808FD6E27AD4884E94820BC333B2DB7727E7B494E9NOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phillip, Since you did suggest that adhering to "pristine principles of the PKIX infrastructure" would get us in deep trouble, does that mean you think relaxing/dropping some of those principles would allow us to avoid some of the trouble? Or in other words, what are you proposing? I'd certainly be interested in hearing it, even if it's not totally in line with how we've done things earlier... Best regards, Pasi ________________________________ From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of ext= Hallam-Baker, Phillip Sent: 23 February, 2009 21:14 To: Stephen Kent; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition Let us see, I suggest that we might need to slay a sacred PKIX cow or two i= n order to make the SHA-n transition work. Stephen: * Describes the suggestion as 'offensive' * Raises a non sequitor about certificate issue policy I canot imagine why Stephen would imagine that a sensible response to a tec= hnical issue would be found in relaxing certificate issue policy criteria, = or for that matter why I would be likely to be suggesting that. I did however anticipate that Stephen would find my proposal objectionable.= But was somewhat surprised that he didn't wait to find out what it was bef= ore objecting. We have a problem here that requires us to work out a coherent transition p= lan for enabling browsers to make use of the stronger security of SHA2 and = SHAn at the earliest possible date taking into account that we have a very = small installed base of SHA2 capable clients and no spec for SHAn. The problem is that you do not gain security from introducing stronger algo= rithms, you only gain security from withdrawing insecure algorithms from us= e. And for better or worse, there are real limits to what the Internet user= base will tollerate for security. So simply adding SHA2 support to existing browsers does not help us much un= less we have a way to retrospectively shut off SHA1 support when it is no l= onger trustworthy. And even that does not help very much as there will be a large number of ce= rtificate customers who want to sell to people who can only use SHA1 capabl= e browsers. And then we have the problem that PKIX does not really have a strategy for = algorithm transition. It has the ability to use multiple algorithms but not= very much thought of how the transition from one to another takes place. ________________________________ From: saag-bounces@ietf.org on behalf of Stephen Kent Sent: Sat 2/21/2009 11:10 AM To: saag@ietf.org Subject: [saag] SHA-1 to SHA-n transition I agree wit Phil's suggestion that we begin work on this topic sooner rathe= r than later. Solutions probably will require coordination between folks i= n both PKIX and TLS, plus some browser experts from the APP area. However, Phil's comment (underling added by me) If we start addressing the problem now we can lay ourselves an insurance po= licy. If we try to insist on the pristine principles of the PKIX infrastruc= ture we are going to be in deep trouble in about five years time. is offensive, at best. Moreover, unless Phil and his favorite browser vendo= rs already have a solution in mind, and he anticipates that it will be obje= ctionable to PKIX, this comment is gratuitous. Since we're talking about how well browsers implement PKI mechanisms in the= context of SSL/TLS, it is worth noting a presentation at last week's Black= Hat conference in D.C. The presentation provided details on how several br= owsers remain vulnerable to attacks because they fails to check the Basic C= onstraints extension. This oversight of one of those pristine principles of= PKIX ( we can use the acronym P3 going forward) and allows a web sites to = act as a CA, based o the EE cert issued to it by any of the trust anchors e= mbedded in the browser. Another vulnerability, and matching MITM attack, is enabled by the issuance= of certs that contain wildcard DNS names. This is not, a violation of P3, = because PKIX caved to pressure from the TLS WG, to accommodate web site ope= rators who wanted to purchase one cert from a TTP that could be used to ver= ify the EE certs for multiple web sites. I argued against this, but lost. T= he phrase "I told you so" comes to mind :-). So, contrary to Phil's assertion that adherence to P3 will get us into deep= trouble in five years (with regard to this transition issue), I believe th= at PKI shortcuts (hacks) in browsers have gotten us into deep trouble for m= any years, and are likely to persist. Steve --_000_808FD6E27AD4884E94820BC333B2DB7727E7B494E9NOKEUMSG01mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SHA-1 to SHA-n transition
Phillip,
 
Since you did suggest that adhering to "pristine p= rinciples=20 of the
PKIX infrastructure" would get us in deep trouble, does that mean= =20 you
think relaxing/dropping some of those principles would allow us=20 to
avoid some of the trouble?

Or in other=20 words, what are you proposing? I'd certainly be interested
in hearing it= ,=20 even if it's not totally in line with how we've done
things earlier...
 
Best regards,
Pasi

From: saag-bounces@ietf.org=20 [mailto:saag-bounces@ietf.org] On Behalf Of ext Hallam-Baker,=20 Phillip
Sent: 23 February, 2009 21:14
To: Stephen Ken= t;=20 saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n=20 transition

Let us see, I suggest that we mig= ht need=20 to slay a sacred PKIX cow or two in order to make the SHA-n transition wo= rk.=20 Stephen:
 
* Describes the suggestion as 'offensive'
* Raises a non sequitor about certificate issue policy
 
I canot imagine why Stephen would imagine that a sensible= =20 response to a technical issue would be found in relaxing certificate issu= e=20 policy criteria, or for that matter why I would be likely to be suggestin= g=20 that.
 
I did however anticipate that Stephen would find my propos= al=20 objectionable. But was somewhat surprised that he didn't wait to find out= what=20 it was before objecting.
 
 
We have a problem here that requires us to work out a cohe= rent=20 transition plan for enabling browsers to make use of the stronger securit= y of=20 SHA2 and SHAn at the earliest possible date taking into account that we h= ave a=20 very small installed base of SHA2 capable clients and no spec for SHAn.
 
The problem is that you do not gain security from introduc= ing=20 stronger algorithms, you only gain security from withdrawing insecure=20 algorithms from use. And for better or worse, there are real=20 limits to what the Internet user base will tollerate for=20 security.
 
So simply adding SHA2 support to existing browsers does no= t help=20 us much unless we have a way to retrospectively shut off SHA1 support whe= n it=20 is no longer trustworthy.
 
And even that does not help very much as there will be a l= arge=20 number of certificate customers who want to sell to people who can only u= se=20 SHA1 capable browsers.
 
And then we have the problem that PKIX does not really hav= e a=20 strategy for algorithm transition. It has the ability to use multiple=20 algorithms but not very much thought of how the transition from one to an= other=20 takes place.
 

From: saag-bounces@ietf.org on behalf= of=20 Stephen Kent
Sent: Sat 2/21/2009 11:10 AM
To:=20 saag@ietf.org
Subject: [saag] SHA-1 to SHA-n=20 transition

I agree wit Phil's suggestion that we begin work on this topic soone= r=20 rather than later.  Solutions probably will require coordination bet= ween=20 folks in both PKIX and TLS, plus some browser experts from the APP area.<= /DIV>

However, Phil's comment (underling added by me)

If we start addressing the problem now = we can=20 lay ourselves an insurance policy. If we try to insist on the pristine= =20 principles of the PKIX infrastructure we are going to be in deep trou= ble=20 in about five years time.

is offensive, at best. Moreover, unless Phil and his favorite browse= r=20 vendors already have a solution in mind, and he anticipates that it will = be=20 objectionable to PKIX, this comment is gratuitous.

Since we're talking about how well browsers implement PKI mechanisms= in=20 the context of SSL/TLS, it is worth noting a presentation at last week's = Black=20 Hat conference in D.C. The presentation provided details on how several=20 browsers remain vulnerable to attacks because they fails to check the Bas= ic=20 Constraints extension. This oversight of one of those pristine principles= of=20 PKIX ( we can use the acronym P3 going forward) and allows a web sites to= act=20 as a CA, based o the EE cert issued to it by any of the trust anchors emb= edded=20 in the browser.

Another vulnerability, and matching MITM attack, is enabled by the=20 issuance of certs that contain wildcard DNS names. This is not, a violati= on of=20 P3, because PKIX caved to pressure from the TLS WG, to accommodate web si= te=20 operators who wanted to purchase one cert from a TTP that could be used t= o=20 verify the EE certs for multiple web sites. I argued against this, but lo= st.=20 The phrase "I told you so" comes to mind :-).

So, contrary to Phil's assertion that adherence to P3 will get us in= to=20 deep trouble in five years (with regard to this transition issue), I beli= eve=20 that PKI shortcuts (hacks) in browsers have gotten us into deep trouble f= or=20 many years, and are likely to persist.

Steve
--_000_808FD6E27AD4884E94820BC333B2DB7727E7B494E9NOKEUMSG01mgd_-- From mcgrew@cisco.com Tue Feb 24 04:11:51 2009 Return-Path: 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 B41F03A6A20 for ; Tue, 24 Feb 2009 04:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xKhPs-69UrQl for ; Tue, 24 Feb 2009 04:11:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 27FF43A67A4 for ; Tue, 24 Feb 2009 04:11:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,258,1233532800"; d="scan'208,217";a="146555350" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2009 12:12:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1OCC9Bl031562; Tue, 24 Feb 2009 04:12:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1OCC9hY018139; Tue, 24 Feb 2009 12:12:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 04:12:09 -0800 Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 04:12:08 -0800 Message-Id: <457F06E3-7F0E-409A-8E0F-C5A653827258@cisco.com> From: David McGrew To: Phillip Hallam-Baker In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E7B494E9@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: multipart/alternative; boundary=Apple-Mail-14--527710453 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 04:12:07 -0800 References: <2788466ED3E31C418E9ACC5C3166155768B2BD@mou1wnexmb09.vcorp.ad.vrsn.com> <808FD6E27AD4884E94820BC333B2DB7727E7B494E9@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Feb 2009 12:12:08.0564 (UTC) FILETIME=[1D6CAB40:01C99679] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15788; t=1235477529; x=1236341529; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[saag]=20SHA-1=20to=20SHA-n=20transitio n |Sender:=20; bh=xsRmVn+s40YFM6ha/Rp1bM999EDWRS/HdiF6Va/ow5Q=; b=TfcF2MXX9qQfI5SE/dW/S+8ygtav2uK7ESn8joMjTkfeSdFN7gmu+AxpZG Dw4PijPiOYSjXvDgLHe3QkuL1NVbZ0/jpow0Bx8E03IrEban+MQneBsVqybb k/k4GNj5yS; Authentication-Results: sj-dkim-3; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:11:51 -0000 --Apple-Mail-14--527710453 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Phillip, On Feb 24, 2009, at 3:48 AM, wrote: > Phillip, > > Since you did suggest that adhering to "pristine principles of the > PKIX infrastructure" would get us in deep trouble, does that mean you > think relaxing/dropping some of those principles would allow us to > avoid some of the trouble? > > Or in other words, what are you proposing? I'd certainly be interested > in hearing it, even if it's not totally in line with how we've done > things earlier... I'll second Pasi's question. If you are alluding to some particular proposal, I don't know what it is. David > > Best regards, > Pasi > > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf > Of ext Hallam-Baker, Phillip > Sent: 23 February, 2009 21:14 > To: Stephen Kent; saag@ietf.org > Subject: Re: [saag] SHA-1 to SHA-n transition > > Let us see, I suggest that we might need to slay a sacred PKIX cow > or two in order to make the SHA-n transition work. Stephen: > > * Describes the suggestion as 'offensive' > * Raises a non sequitor about certificate issue policy > > I canot imagine why Stephen would imagine that a sensible response > to a technical issue would be found in relaxing certificate issue > policy criteria, or for that matter why I would be likely to be > suggesting that. > > I did however anticipate that Stephen would find my proposal > objectionable. But was somewhat surprised that he didn't wait to > find out what it was before objecting. > > > We have a problem here that requires us to work out a coherent > transition plan for enabling browsers to make use of the stronger > security of SHA2 and SHAn at the earliest possible date taking into > account that we have a very small installed base of SHA2 capable > clients and no spec for SHAn. > > The problem is that you do not gain security from introducing > stronger algorithms, you only gain security from withdrawing > insecure algorithms from use. And for better or worse, there are > real limits to what the Internet user base will tollerate for > security. > > So simply adding SHA2 support to existing browsers does not help us > much unless we have a way to retrospectively shut off SHA1 support > when it is no longer trustworthy. > > And even that does not help very much as there will be a large > number of certificate customers who want to sell to people who can > only use SHA1 capable browsers. > > And then we have the problem that PKIX does not really have a > strategy for algorithm transition. It has the ability to use > multiple algorithms but not very much thought of how the transition > from one to another takes place. > > > From: saag-bounces@ietf.org on behalf of Stephen Kent > Sent: Sat 2/21/2009 11:10 AM > To: saag@ietf.org > Subject: [saag] SHA-1 to SHA-n transition > > I agree wit Phil's suggestion that we begin work on this topic > sooner rather than later. Solutions probably will require > coordination between folks in both PKIX and TLS, plus some browser > experts from the APP area. > > However, Phil's comment (underling added by me) > > If we start addressing the problem now we can lay ourselves an > insurance policy. If we try to insist on the pristine principles of > the PKIX infrastructure we are going to be in deep trouble in about > five years time. > > is offensive, at best. Moreover, unless Phil and his favorite > browser vendors already have a solution in mind, and he anticipates > that it will be objectionable to PKIX, this comment is gratuitous. > > Since we're talking about how well browsers implement PKI mechanisms > in the context of SSL/TLS, it is worth noting a presentation at last > week's Black Hat conference in D.C. The presentation provided > details on how several browsers remain vulnerable to attacks because > they fails to check the Basic Constraints extension. This oversight > of one of those pristine principles of PKIX ( we can use the acronym > P3 going forward) and allows a web sites to act as a CA, based o the > EE cert issued to it by any of the trust anchors embedded in the > browser. > > Another vulnerability, and matching MITM attack, is enabled by the > issuance of certs that contain wildcard DNS names. This is not, a > violation of P3, because PKIX caved to pressure from the TLS WG, to > accommodate web site operators who wanted to purchase one cert from > a TTP that could be used to verify the EE certs for multiple web > sites. I argued against this, but lost. The phrase "I told you so" > comes to mind :-). > > So, contrary to Phil's assertion that adherence to P3 will get us > into deep trouble in five years (with regard to this transition > issue), I believe that PKI shortcuts (hacks) in browsers have gotten > us into deep trouble for many years, and are likely to persist. > > Steve > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-14--527710453 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Phillip,

On Feb 24, 2009, at 3:48 AM, = <Pasi.Eronen@nokia.com> = wrote:

Phillip,
 
Since you did suggest that = adhering to "pristine principles of the
PKIX infrastructure" would = get us in deep trouble, does that mean you
think relaxing/dropping = some of those principles would allow us to
avoid some of the = trouble?

Or in other words, what are you proposing? I'd certainly be = interested
in hearing it, even if it's not totally in line with how = we've done
things = earlier...

I'll second Pasi's question.   If you = are alluding to some particular proposal, I don't know what it is. =  

David

 
Best regards,
Pasi

From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of ext Hallam-Baker, = Phillip
Sent: 23 February, 2009 = 21:14
To: Stephen Kent; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n = transition

Let us see, I suggest that we might need to slay a sacred = PKIX cow or two in order to make the SHA-n transition work. = Stephen:
 
* Describes = the suggestion as 'offensive'
* Raises a non = sequitor about certificate issue policy
 
I canot imagine why Stephen = would imagine that a sensible response to a technical issue would be = found in relaxing certificate issue policy criteria, or for that matter = why I would be likely to be suggesting that.
 
I did however anticipate that = Stephen would find my proposal objectionable. But was somewhat surprised = that he didn't wait to find out what it was before objecting.
 
 
We = have a problem here that requires us to work out a coherent transition = plan for enabling browsers to make use of the stronger security of SHA2 = and SHAn at the earliest possible date taking into account that we have = a very small installed base of SHA2 capable clients and no spec for = SHAn.
 
The problem is = that you do not gain security from introducing stronger algorithms, you = only gain security from withdrawing insecure algorithms from use. And = for better or worse, there are real limits to what = the Internet user base will tollerate for security.
 
So simply adding SHA2 support = to existing browsers does not help us much unless we have a way to = retrospectively shut off SHA1 support when it is no longer = trustworthy.
 
And even = that does not help very much as there will be a large number of = certificate customers who want to sell to people who can only use SHA1 = capable browsers.
 
And = then we have the problem that PKIX does not really have a strategy for = algorithm transition. It has the ability to use multiple algorithms but = not very much thought of how the transition from one to another takes = place.
 

From: saag-bounces@ietf.org on behalf of Stephen = Kent
Sent: Sat= 2/21/2009 11:10 AM
To: saag@ietf.org
Subject: [saag] SHA-1 to SHA-n = transition

I agree wit Phil's suggestion = that we begin work on this topic sooner rather than later.  = Solutions probably will require coordination between folks in both PKIX = and TLS, plus some browser experts from the APP = area.

However, Phil's comment (underling added = by me)

If we = start addressing the problem now we can lay ourselves an insurance = policy. If we try to insist on the pristine principles of the = PKIX infrastructure we are going to be in deep = trouble in about five years time.

is = offensive, at best. Moreover, unless Phil and his favorite browser = vendors already have a solution in mind, and he anticipates that it will = be objectionable to PKIX, this comment is = gratuitous.

Since we're talking about how well = browsers implement PKI mechanisms in the context of SSL/TLS, it is worth = noting a presentation at last week's Black Hat conference in D.C. The = presentation provided details on how several browsers remain vulnerable = to attacks because they fails to check the Basic Constraints extension. = This oversight of one of those pristine principles of PKIX ( we can use = the acronym P3 going forward) and allows a web sites to act as a CA, = based o the EE cert issued to it by any of the trust anchors embedded in = the browser.

Another vulnerability, and = matching MITM attack, is enabled by the issuance of certs that contain = wildcard DNS names. This is not, a violation of P3, because PKIX caved = to pressure from the TLS WG, to accommodate web site operators who = wanted to purchase one cert from a TTP that could be used to verify the = EE certs for multiple web sites. I argued against this, but lost. The = phrase "I told you so" comes to mind :-).

So, = contrary to Phil's assertion that adherence to P3 will get us into deep = trouble in five years (with regard to this transition issue), I believe = that PKI shortcuts (hacks) in browsers have gotten us into deep trouble = for many years, and are likely to = persist.

Steve
__________= _____________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/m= ailman/listinfo/saag

= --Apple-Mail-14--527710453-- From pbaker@verisign.com Tue Feb 24 07:01:51 2009 Return-Path: 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 A81703A692A for ; Tue, 24 Feb 2009 07:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 sTOPUsUVqtXj for ; Tue, 24 Feb 2009 07:01:49 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 937663A67A2 for ; Tue, 24 Feb 2009 07:01:49 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1OF25uc019701; Tue, 24 Feb 2009 07:02:05 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 07:02:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99690.DABE4106" Date: Tue, 24 Feb 2009 07:02:04 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2C0@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmUPu2BuBpQlTXAQDetUEXQp8IetwBp3nWtACN79IAABdwS0g== References: <2788466ED3E31C418E9ACC5C3166155768B2BD@mou1wnexmb09.vcorp.ad.vrsn.com> <808FD6E27AD4884E94820BC333B2DB7727E7B494E9@NOK-EUMSG-01.mgdnok.nokia.com> From: "Hallam-Baker, Phillip" To: , X-OriginalArrivalTime: 24 Feb 2009 15:02:05.0190 (UTC) FILETIME=[DB165260:01C99690] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:01:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99690.DABE4106 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, traditionally, PKIX is based on a Kohnfelder style certificate = architecture. At the time (1977) it was believed that it was impractical = to run a directory of keys, or update keys frequently. The Internet such = as it was ran at dial up speeds. =20 Since then a number of things have happened =20 1) The original monolithic PEM root was replaced with a heterachy. 2) CRLs became too big to be useful for large CAs. 3) Network connectivity became dependable and ubiquitous. 4) OCSP began to be used as the default revocation checking mechanism = (vista). =20 What I think we need to do is to create an insurance policy that uses = the OCSP token as a fallback certificate mechanism as follows: =20 1) Client software authors create a Rivest style 'suicide note' for the = SHA1 algorithm (OK he did it just for certs, this is for algs, same = idea). 1a) They chose a random number x which is appropriately sequestered. 1b) They generate the witness value W =3D SHA1(x)=20 1c) Code in the browser recognizes a suicide note as being authentic if = it contains a value x such that SHA1(x) =3D W 1d) If the suicide note is delivered the browser will henceforth not = accept a certificate if the authentication chain is dependent on SHA1. =20 2) A legacy browser may still make use of a SHA1 authenticated = certificate, provided that it can obtain an alternative certification = route via an acceptable digest in the OCSP token. 2a) Client asks for an OCSP token signed with SHA2 2b) Server returns token signed with SHA2 and contains a digest of the = original cert in SHA2 =20 [Hold your horses on efficiency grumbles, OCSP stapling, short lived = certs can be used] [Oh and yes, do the same for all algorithms] =20 =20 OK so that meets our security requirements, it allows a browser to be = delivered today that works with existing SHA1 certificates right up = until the moment that it is deemed no longer safe to use SHA1. =20 So for example, let us imagine that we deployed this scheme on the day = that the SHA1 problems were first uncovered. At that point the = population of Web browsers would be: =20 [The SHA2 browser supporting SHA1 via a suicide note scheme, ditto for = SHAn so total is more than 100%] =20 SHA1: 100% SHA2: 0% SHAn: 0% =20 So if SHA1 was compromised then, every browser in creation would have to = be upgraded which would be a party for the attackers since they are very = good at exploiting chaos and in particular transition arrangements. = Every time a bank merges they send out phishing attacks. =20 Now lets wind forward to maybe where we will be in a few years: =20 SHA1: 100% SHA2: 50% SHAn: 5% =20 At this point SHA1 is still deemed to be acceptably secure, there is a = large population of SHA2 browsers. But any site that buys a SHA2 certs = would automatically lose half their business and they are not going to = do that. This is the problem with algorithm transitions. =20 Now lets wind forward to where I would hope we are when SHA1 starts to = look really bad, let us imagine that we have a collision attack but not = a first pre-image, lets also imagine that we have an acceptable amount = of randomness to foil exploits: =20 SHA1: 30% SHA2: 80% SHAn: 20% =20 The suicide note has been delivered. We are worried anough about the = security of SHA1 to require CAs to deliver SHA2 validated tokens. But = even so there is a significant proportion of browsers using SHA1 and = businesses want to continue to use. =20 At this point, there will of course be some people saying cut the old = browsers lose, but that will create chaos that the criminals will = exploit. Better to withdraw the old algorithm gradually.=20 =20 =20 Now compare this withdrawal scheme with what happens if you try to do a = hard cut-over. This time the decision is made by the browser provider = and the significant quantity is the number of certificates in the = population. In particular, remember that CAs will sell what their = customers demand and their customers will demand certificates that work = with the greatest number of browsers and no browser provider can cut = over if the proportion of SHA1 certs is greater than 50% =20 So on day 1 the population of certs is: =20 SHA1: 100% =20 Therefore every browser must support SHA1 and every business will buy an = SHA1 cert, so on day 2 the population of certs will be=20 =20 SHA1: 100% =20 Therefore every browser must support SHA1 and every business will buy an = SHA1 cert, so on day n+1 the population of certs will be=20 =20 SHA1: 100% =20 The induction goes on forever. The only way to escape it is to create a = bifurcated transition path so that new browsers can take advantage of = better security without impacting the old. =20 =20 On the efficiency issue, there are two possible fixes. The simplest is = to deploy OCSP token stapling in SSL so that a browser gets a token and = cert chain all in one go.=20 =20 Another possibility is to create short lived certs and provide a = selection mechanism. This is more expensive in bits however as two = complete cert chains are required. =20 =20 So in conclusion, we can manage this transition, but only if we first = abandon the foolish notion that people are going to do the right thing = of their own accord. Even though every party in this system is aware of = the right thing, none is able to do it because the business imperative = is to keep the system running one more day. =20 Looking at the deployed infrastructure, the simplest fix to me is to use = the OCSP path. Note that this does effectively turn PKIX into a key = centric model PKI. The cert chains are then isomorphic to XKMS. =20 =20 ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tue 2/24/2009 6:48 AM To: Hallam-Baker, Phillip; saag@ietf.org Subject: RE: [saag] SHA-1 to SHA-n transition Phillip, =20 Since you did suggest that adhering to "pristine principles of the PKIX infrastructure" would get us in deep trouble, does that mean you think relaxing/dropping some of those principles would allow us to avoid some of the trouble? Or in other words, what are you proposing? I'd certainly be interested in hearing it, even if it's not totally in line with how we've done things earlier... =20 Best regards, Pasi ________________________________ From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of = ext Hallam-Baker, Phillip Sent: 23 February, 2009 21:14 To: Stephen Kent; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =09 =09 Let us see, I suggest that we might need to slay a sacred PKIX cow or = two in order to make the SHA-n transition work. Stephen:=20 =20 * Describes the suggestion as 'offensive' * Raises a non sequitor about certificate issue policy =20 I canot imagine why Stephen would imagine that a sensible response to a = technical issue would be found in relaxing certificate issue policy = criteria, or for that matter why I would be likely to be suggesting = that.=20 =20 I did however anticipate that Stephen would find my proposal = objectionable. But was somewhat surprised that he didn't wait to find = out what it was before objecting. =20 =20 We have a problem here that requires us to work out a coherent = transition plan for enabling browsers to make use of the stronger = security of SHA2 and SHAn at the earliest possible date taking into = account that we have a very small installed base of SHA2 capable clients = and no spec for SHAn. =20 The problem is that you do not gain security from introducing stronger = algorithms, you only gain security from withdrawing insecure algorithms = from use. And for better or worse, there are real limits to what the = Internet user base will tollerate for security. =20 So simply adding SHA2 support to existing browsers does not help us = much unless we have a way to retrospectively shut off SHA1 support when = it is no longer trustworthy.=20 =20 And even that does not help very much as there will be a large number = of certificate customers who want to sell to people who can only use = SHA1 capable browsers. =20 And then we have the problem that PKIX does not really have a strategy = for algorithm transition. It has the ability to use multiple algorithms = but not very much thought of how the transition from one to another = takes place. =20 ________________________________ From: saag-bounces@ietf.org on behalf of Stephen Kent Sent: Sat 2/21/2009 11:10 AM To: saag@ietf.org Subject: [saag] SHA-1 to SHA-n transition =09 =09 I agree wit Phil's suggestion that we begin work on this topic sooner = rather than later. Solutions probably will require coordination between = folks in both PKIX and TLS, plus some browser experts from the APP area. However, Phil's comment (underling added by me) If we start addressing the problem now we can lay ourselves an = insurance policy. If we try to insist on the pristine principles of the = PKIX infrastructure we are going to be in deep trouble in about five = years time. is offensive, at best. Moreover, unless Phil and his favorite browser = vendors already have a solution in mind, and he anticipates that it will = be objectionable to PKIX, this comment is gratuitous. Since we're talking about how well browsers implement PKI mechanisms in = the context of SSL/TLS, it is worth noting a presentation at last week's = Black Hat conference in D.C. The presentation provided details on how = several browsers remain vulnerable to attacks because they fails to = check the Basic Constraints extension. This oversight of one of those = pristine principles of PKIX ( we can use the acronym P3 going forward) = and allows a web sites to act as a CA, based o the EE cert issued to it = by any of the trust anchors embedded in the browser. Another vulnerability, and matching MITM attack, is enabled by the = issuance of certs that contain wildcard DNS names. This is not, a = violation of P3, because PKIX caved to pressure from the TLS WG, to = accommodate web site operators who wanted to purchase one cert from a = TTP that could be used to verify the EE certs for multiple web sites. I = argued against this, but lost. The phrase "I told you so" comes to mind = :-). So, contrary to Phil's assertion that adherence to P3 will get us into = deep trouble in five years (with regard to this transition issue), I = believe that PKI shortcuts (hacks) in browsers have gotten us into deep = trouble for many years, and are likely to persist. Steve ------_=_NextPart_001_01C99690.DABE4106 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SHA-1 to SHA-n transition=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
OK, = traditionally, PKIX is based on a Kohnfelder style certificate = architecture. At the time (1977) it was believed that it was = impractical to run a directory of keys, or update keys frequently. The = Internet such as it was ran at dial up speeds.
=0A=
 
=0A=
Since then a number of things = have happened
=0A=
 
=0A=
1) The original monolithic = PEM root was replaced with a heterachy.
=0A=
2) CRLs became too big to be = useful for large CAs.
=0A=
3) Network connectivity = became dependable and ubiquitous.
=0A=
4) OCSP began to be used as = the default revocation checking mechanism (vista).
=0A=
 
=0A=
What I think we need to do is = to create an insurance policy that uses the OCSP token as a = fallback certificate mechanism as follows:
=0A=
 
=0A=
1) Client software = authors create a Rivest style 'suicide note' for the SHA1 algorithm = (OK he did it just for certs, this is for algs, same idea).
=0A=
1a) They chose a random = number x which is appropriately sequestered.
=0A=
1b) They generate the witness = value W =3D SHA1(x) 
=0A=
1c) Code in the browser = recognizes a suicide note as being authentic if it contains a value x = such that SHA1(x) =3D W
=0A=
1d) If the suicide note is = delivered the browser will henceforth not accept a certificate if the = authentication chain is dependent on SHA1.
=0A=
 
=0A=
2) A legacy browser may still = make use of a SHA1 authenticated certificate, provided that it can = obtain an alternative certification route via an acceptable digest in = the OCSP token.
=0A=
2a) Client asks for an OCSP = token signed with SHA2
=0A=
2b) Server returns token = signed with SHA2 and contains a digest of the original cert in = SHA2
=0A=
 
=0A=
[Hold your horses on = efficiency grumbles, OCSP stapling, short lived certs can be = used]
=0A=
[Oh and yes, do the same for = all algorithms]
=0A=
 
=0A=
 
=0A=
OK so that meets our security = requirements, it allows a browser to be delivered today that works with = existing SHA1 certificates right up until the moment that it is deemed = no longer safe to use SHA1.
=0A=
 
=0A=
So for example, let us = imagine that we deployed this scheme on the day that the SHA1 problems = were first uncovered. At that point the population of Web browsers would = be:
=0A=
 
=0A=
[The SHA2 browser supporting = SHA1 via a suicide note scheme, ditto for SHAn so total is more than = 100%]
=0A=
 
=0A=
SHA1: 100%
=0A=
SHA2: 0%
=0A=
SHAn: 0%
=0A=
 
=0A=
So if SHA1 was compromised = then, every browser in creation would have to be upgraded which would be = a party for the attackers since they are very good at exploiting chaos = and in particular transition arrangements. Every time a bank merges they = send out phishing attacks.
=0A=
 
=0A=
Now lets wind forward to = maybe where we will be in a few years:
=0A=
 
=0A=
=0A=
SHA1: 100%
=0A=
SHA2: 50%
=0A=
SHAn: = 5%
=0A=
 
=0A=
At this point SHA1 is still = deemed to be acceptably secure, there is a large population of SHA2 = browsers. But any site that buys a SHA2 certs would automatically lose = half their business and they are not going to do that. This is the = problem with algorithm transitions.
=0A=
 
=0A=
Now lets wind forward to = where I would hope we are when SHA1 starts to look really bad, let us = imagine that we have a collision attack but not a first pre-image, lets = also imagine that we have an acceptable amount of randomness to foil = exploits:
=0A=
 
=0A=
=0A=
SHA1: 30%
=0A=
SHA2: 80%
=0A=
SHAn: 20%
=0A=
 
=0A=
The suicide note has been = delivered. We are worried anough about the security of SHA1 to require = CAs to deliver SHA2 validated tokens. But even so there is a significant = proportion of browsers using SHA1 and businesses want to continue to = use.
=0A=
 
=0A=
At this point, there will of = course be some people saying cut the old browsers lose, but that will = create chaos that the criminals will exploit. Better to withdraw the old = algorithm gradually.
=0A=
 
=0A=
 
=0A=
Now compare this withdrawal = scheme with what happens if you try to do a hard cut-over. This time the = decision is made by the browser provider and the significant quantity is = the number of certificates in the population. In particular, remember = that CAs will sell what their customers demand and their customers will = demand certificates that work with the greatest number of browsers and = no browser provider can cut over if the proportion of SHA1 certs is = greater than 50%
=0A=
 
=0A=
So on day 1 the population of = certs is:
=0A=
 
=0A=
SHA1: 100%
=0A=
 
=0A=
Therefore every browser must = support SHA1 and every business will buy an SHA1 cert, so on day 2 the = population of certs will be
=0A=
 
=0A=
SHA1: 100%
=0A=
 
=0A=
Therefore every browser must = support SHA1 and every business will buy an SHA1 cert, so on = day n+1 the population of certs will be
=0A=
 
=0A=
SHA1: 100%
=0A=
 
=0A=
The induction goes on = forever. The only way to escape it is to create a bifurcated transition = path so that new browsers can take advantage of better security without = impacting the old.
=0A=
 
=0A=
 
=0A=
On the efficiency issue, = there are two possible fixes. The simplest is to deploy OCSP token = stapling in SSL so that a browser gets a token and cert chain all in one = go.
=0A=
 
=0A=
Another possibility is to = create short lived certs and provide a selection mechanism. This is more = expensive in bits however as two complete cert chains are = required.
=0A=
 
=0A=
 
=0A=
So in conclusion, we can = manage this transition, but only if we first abandon the foolish notion = that people are going to do the right thing of their own accord. Even = though every party in this system is aware of the right thing, none is = able to do it because the business imperative is to keep the system = running one more day.
=0A=
 
=0A=
Looking at the deployed = infrastructure, the simplest fix to me is to use the OCSP path. Note = that this does effectively turn PKIX into a key centric model PKI. The = cert chains are then isomorphic to XKMS.
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
From: = Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Tue = 2/24/2009 6:48 AM
To: Hallam-Baker, Phillip; = saag@ietf.org
Subject: RE: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=
Phillip,
=0A=
 
=0A=
Since you did suggest that = adhering to "pristine principles of the
PKIX infrastructure" would = get us in deep trouble, does that mean you
think relaxing/dropping = some of those principles would allow us to
=0A=
avoid some of the = trouble?
=0A=

Or in other words, what are you proposing? I'd certainly be = interested
in hearing it, even if it's not totally in line with how = we've done
=0A=
things = earlier...
=0A=
 
=0A=
Best regards,
=0A=
Pasi

=0A=
=0A=
=0A=
=0A= From: saag-bounces@ietf.org = [mailto:saag-bounces@ietf.org] On Behalf Of ext Hallam-Baker, = Phillip
Sent: 23 February, 2009 21:14
To: Stephen = Kent; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=
Let us see, I suggest that we = might need to slay a sacred PKIX cow or two in order to make the SHA-n = transition work. Stephen:
=0A=
 
=0A=
* Describes the suggestion as 'offensive'
=0A=
* Raises a non sequitor about certificate issue = policy
=0A=
 
=0A=
I canot imagine why Stephen would imagine that a sensible = response to a technical issue would be found in relaxing certificate = issue policy criteria, or for that matter why I would be likely to be = suggesting that.
=0A=
 
=0A=
I did however anticipate that Stephen would find my = proposal objectionable. But was somewhat surprised that he didn't wait = to find out what it was before objecting.
=0A=
 
=0A=
 
=0A=
We have a problem here that requires us to work out a = coherent transition plan for enabling browsers to make use of the = stronger security of SHA2 and SHAn at the earliest possible date taking = into account that we have a very small installed base of SHA2 capable = clients and no spec for SHAn.
=0A=
 
=0A=
The problem is that you do not gain security from = introducing stronger algorithms, you only gain security from withdrawing = insecure algorithms from use. And for better or worse, there are real = limits to what the Internet user base will tollerate for = security.
=0A=
 
=0A=
So simply adding SHA2 support to existing browsers does = not help us much unless we have a way to retrospectively shut off SHA1 = support when it is no longer trustworthy.
=0A=
 
=0A=
And even that does not help very much as there will be a = large number of certificate customers who want to sell to people who can = only use SHA1 capable browsers.
=0A=
 
=0A=
And then we have the problem that PKIX does not really = have a strategy for algorithm transition. It has the ability to use = multiple algorithms but not very much thought of how the transition from = one to another takes place.
=0A=
 
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Stephen Kent
Sent: Sat 2/21/2009 11:10 = AM
To: saag@ietf.org
Subject: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=
I agree wit Phil's suggestion that we begin work on this topic = sooner rather than later.  Solutions probably will require = coordination between folks in both PKIX and TLS, plus some browser = experts from the APP area.
=0A=

=0A=
However, Phil's comment (underling added by me)
=0A=

=0A=
If we start addressing the problem now = we can lay ourselves an insurance policy. If we try to insist on the = pristine principles of the PKIX infrastructure we are going to be in = deep trouble in about five years time.
=0A=

=0A=
is offensive, at best. Moreover, unless Phil and his favorite = browser vendors already have a solution in mind, and he anticipates that = it will be objectionable to PKIX, this comment is gratuitous.
=0A=

=0A=
Since we're talking about how well browsers implement PKI = mechanisms in the context of SSL/TLS, it is worth noting a presentation = at last week's Black Hat conference in D.C. The presentation provided = details on how several browsers remain vulnerable to attacks because = they fails to check the Basic Constraints extension. This oversight of = one of those pristine principles of PKIX ( we can use the acronym P3 = going forward) and allows a web sites to act as a CA, based o the EE = cert issued to it by any of the trust anchors embedded in the = browser.
=0A=

=0A=
Another vulnerability, and matching MITM attack, is enabled by the = issuance of certs that contain wildcard DNS names. This is not, a = violation of P3, because PKIX caved to pressure from the TLS WG, to = accommodate web site operators who wanted to purchase one cert from a = TTP that could be used to verify the EE certs for multiple web sites. I = argued against this, but lost. The phrase "I told you so" comes to mind = :-).
=0A=

=0A=
So, contrary to Phil's assertion that adherence to P3 will get us = into deep trouble in five years (with regard to this transition issue), = I believe that PKI shortcuts (hacks) in browsers have gotten us into = deep trouble for many years, and are likely to persist.
=0A=

=0A=
Steve
------_=_NextPart_001_01C99690.DABE4106-- From jhutz@cmu.edu Wed Feb 25 08:29:18 2009 Return-Path: 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 CD8FE3A6AEC for ; Wed, 25 Feb 2009 08:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 Z+4osSfzVGDR for ; Wed, 25 Feb 2009 08:29:17 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id C2CFE3A67B5 for ; Wed, 25 Feb 2009 08:29:17 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1PGTUaj021101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 11:29:32 -0500 (EST) Date: Wed, 25 Feb 2009 11:29:30 -0500 From: Jeffrey Hutzelman To: "Hallam-Baker, Phillip" , Stephen Kent , saag@ietf.org Message-ID: <5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu> In-Reply-To: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu> References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 16:29:18 -0000 --On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip" wrote: > Let us see, I suggest that we might need to slay a sacred PKIX cow or two > in order to make the SHA-n transition work. Stephen: > * Describes the suggestion as 'offensive' Yes, this sort of crack is offensive and counterproductive. Knock it off. If you have a proposal to make, then fine, make it. Don't start off by deliberately attacking people who you think will oppose your proposal, on the basis of arguments that haven't yet been made and probably won't be. _That_ is offensive. So, by the way, is the "sacred cow" comparsion, to some folks. Your actual proposal makes a number of very large assumptions, such as... - that interactive Web browsers with access to stable storage and nearly-continuous access to the connected Internet are the only problem worth solving. Possibly true for your company, and other CA's, and browser vendors. Definitely _not_ true for the IETF. - that because certain conditions hold now, they always will Definitely not true for anyone, outside of an extremely tightly controlled environment, and maybe not even then. - that it is OK for browser software to silently make configuration changes based on external stimulus and without the user's consent. This is definitely not true, and will actively screw people if the browser vendors ever implement your proposal. Suppose you distribute your so-called "suicide note", causing my browser to reconfigure itself (silently and without my consent) to disallow SHA-1. Unfortunately, my entire enterprise PKI was based on SHA-1 certificates, and you have just thrown my organization into chaos, potentially costing billions of dollars. Can you imagine the lawsuits when Microsoft does this to a major financial institution? Can you imagine the economic impact when Microsoft does this to _every_ major financial institution? -- Jeff From pbaker@verisign.com Wed Feb 25 09:37:29 2009 Return-Path: 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 0439328C25E for ; Wed, 25 Feb 2009 09:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.991 X-Spam-Level: X-Spam-Status: No, score=-4.991 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 PF9UziXs39Bm for ; Wed, 25 Feb 2009 09:37:27 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 8598C28C247 for ; Wed, 25 Feb 2009 09:37:27 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1PHbYEH010433; Wed, 25 Feb 2009 09:37:34 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 09:37:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9976F.BD8EA0C2" Date: Wed, 25 Feb 2009 09:37:33 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmXZkIHNTtGqAcDRpSQz8zKbJ8T6AAA6ulY References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu> <5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu> From: "Hallam-Baker, Phillip" To: "Jeffrey Hutzelman" , "Stephen Kent" , X-OriginalArrivalTime: 25 Feb 2009 17:37:34.0933 (UTC) FILETIME=[BE75E050:01C9976F] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:37:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9976F.BD8EA0C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As it happens, what I was referring to is that I do not like the look of = this scheme. It is an ugly hack. However I dislike the consequences of = not addressing this issue up front rather more and I really don't see = how a less hackish solution will serve. =20 Now I did get offended by the implication that we should not consider = technical issues if they might offend people. As with an earlier case = where a past Security AD blocked a necessary protocol change because it = 'gave him a bad gut feeling'. While making decisions based on the = examination of intestines was all the rage in ancient Rome, it should be = avoided. =20 =20 On the points you raise. =20 1) If a device is not connected to a communications network, then why = would it need to establish a cryptographic communication security = context? =20 The offline PKI argument is seductive, but when you get down to case = analysis, the real purpose of PKI is to communicate. The security = guarantees that are possible in the offline case will always be lower = than can be achieved in the online case. =20 If the device is not connected to a network realtime then issues such as = certificate status are going to be have to be handled by something that = is online and can pass a satisfactory proof of trustworthiness on. =20 But in any case, the issues are entirely addressed by OCSP token = stapling which is possible in SSL and S/MIME and any XML signature based = protocol. =20 =20 2) 'that because certain conditions hold now, they always will' =20 I do not understand the relevance. What the claim amounts to is = asserting that because my prediction of the future might be falible, no = precidtion can be made, all outcomes are equally likely. =20 You base strategy on your best knowledge of the current situation and = your best faith prediction of the consequences. If someone wants to = challenge that analysis they should provide new facts and/or argue that = different consequences are likely. =20 We have long experience of what the world does when we tell it our view = of what the best thing is from a security perspective - they ignore us = do what they think is in their best short term interests. =20 =20 3) 'that it is OK for browser software to silently make configuration = changes based on external stimulus and without the user's consent.' Here you might have a point. But I am not certain. In any case it is an = implementation detail. What degree of control end users have is a policy = matter. Most users are entirely happy for Microsoft or McAfee to control = security on their PC. =20 Kill switches are unfortunately necessary at times. What is important is = not so much the existence of the kill switch as who is in control. =20 In this particular case the whole purpose is to put enterprises and CAs = on notice that a change is going to be necessary and that they have to = start planning for it right now without setting a premature termination = date. All an enterprise need do to plan for the transition is to upgrade = their internal CA and their Web servers before SHA1 is actually broken.=20 =20 One option would be to allow the end user (or system manager) to = over-ride the suicide note - provided that an equally secure mechanism = was used for the control channel. Another would be to allow local = configuration of the suicide note issuer. =20 I am not to sure about the consequences for your internal CA. If the = roots are embedded in the browser then why not expect them to be handled = according to current best practice? If the roots are not embedded then = you might as well treat them as self signed certificates and allow a = per-site exception. =20 I am not actually a fan of turning off certificates. An HTTP connection = that is secured to an untrustworthy key is still better from a security = point of view than one that is en-clair. My consistent suggestion has = been that any browser should accept any key to start SSL unless the user = types in https:// at the command line. The only difference being that = the browser should not tell the user that SSL is in use in primary = chrome. =20 =20 =20 =20 ________________________________ From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Wed 2/25/2009 11:29 AM To: Hallam-Baker, Phillip; Stephen Kent; saag@ietf.org Cc: jhutz@cmu.edu Subject: Re: [saag] SHA-1 to SHA-n transition --On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip" wrote: > Let us see, I suggest that we might need to slay a sacred PKIX cow or = two > in order to make the SHA-n transition work. Stephen: > * Describes the suggestion as 'offensive' Yes, this sort of crack is offensive and counterproductive. Knock it = off. If you have a proposal to make, then fine, make it. Don't start off by deliberately attacking people who you think will = oppose your proposal, on the basis of arguments that haven't yet been made and probably won't be. _That_ is offensive. So, by the way, is the "sacred cow" comparsion, to some folks. Your actual proposal makes a number of very large assumptions, such = as... - that interactive Web browsers with access to stable storage and nearly-continuous access to the connected Internet are the only problem worth solving. Possibly true for your company, and other CA's, and browser vendors. Definitely _not_ true for the IETF. - that because certain conditions hold now, they always will Definitely not true for anyone, outside of an extremely tightly controlled environment, and maybe not even then. - that it is OK for browser software to silently make configuration changes based on external stimulus and without the user's consent. This is definitely not true, and will actively screw people if the browser vendors ever implement your proposal. Suppose you distribute your so-called "suicide note", causing my browser to reconfigure = itself (silently and without my consent) to disallow SHA-1. Unfortunately, my entire enterprise PKI was based on SHA-1 certificates, and you have just thrown my organization into chaos, potentially costing billions of dollars. Can you imagine the lawsuits when Microsoft does this to a major financial institution? Can you imagine the economic impact when Microsoft does this to _every_ major financial institution? -- Jeff ------_=_NextPart_001_01C9976F.BD8EA0C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
As it happens, what I was referring to is that I do = not like the look of this scheme. It is an ugly hack. However I dislike = the consequences of not addressing this issue up front rather more and I = really don't see how a less hackish solution will serve.
=0A=
 
=0A=
Now I did get offended by the implication that we should = not consider technical issues if they might offend people. As with an = earlier case where a past Security AD blocked a necessary protocol = change because it 'gave him a bad gut feeling'. While making decisions = based on the examination of intestines was all the rage in ancient Rome, = it should be avoided.
=0A=
 
=0A=
 
=0A=
On the points you raise.
=0A=
 
=0A=
1) If a device is not connected to a communications = network, then why would it need to establish a cryptographic = communication security context?
=0A=
 
=0A=
The offline PKI argument is seductive, but when you get = down to case analysis, the real purpose of PKI is to communicate. The = security guarantees that are possible in the offline case will always be = lower than can be achieved in the online case.
=0A=
 
=0A=
If the device is not connected to a network realtime then = issues such as certificate status are going to be have to be handled by = something that is online and can pass a satisfactory proof of = trustworthiness on.
=0A=
 
=0A=
But in any case, the issues are entirely addressed by = OCSP token stapling which is possible in SSL and S/MIME and any XML = signature based protocol.
=0A=
 
=0A=
 
=0A=
2) 'that because certain conditions hold now, they always = will'
=0A=
 
=0A=
I do not understand the relevance. What the claim amounts = to is asserting that because my prediction of the future might be = falible, no precidtion can be made, all outcomes are equally = likely.
=0A=
 
=0A=
You base strategy on your best knowledge of the current = situation and your best faith prediction of the consequences. If someone = wants to challenge that analysis they should provide new facts = and/or argue that different consequences are likely.
=0A=
 
=0A=
We have long experience of what the world does when we = tell it our view of what the best thing is from a security perspective - = they ignore us do what they think is in their best short term = interests.
=0A=
 
=0A=
 
=0A=
3)  'that it is OK for browser software to silently = make configuration  changes based on external stimulus and without = the user's consent.'
=0A=
Here you might have a point. But I am not certain. In any = case it is an implementation detail. What degree of control end users = have is a policy matter. Most users are entirely happy for Microsoft or = McAfee to control security on their PC.
=0A=
 
=0A=
Kill switches are unfortunately necessary at times. What = is important is not so much the existence of the kill switch as who = is in control.
=0A=
 
=0A=
In this particular case the whole purpose is to put = enterprises and CAs on notice that a change is going to be necessary and = that they have to start planning for it right now without setting a = premature termination date. All an enterprise need do to plan for the = transition is to upgrade their internal CA and their Web servers before = SHA1 is actually broken.
=0A=
 
=0A=
One option would be to allow the end user (or system = manager) to over-ride the suicide note - provided that an equally secure = mechanism was used for the control channel. Another would be to allow = local configuration of the suicide note issuer.
=0A=
 
=0A=
I am not to sure about the consequences for your internal = CA. If the roots are embedded in the browser then why not expect them to = be handled according to current best practice? If the roots are not = embedded then you might as well treat them as self signed certificates = and allow a per-site exception.
=0A=
 
=0A=
I am not actually a fan of turning off certificates. An = HTTP connection that is secured to an untrustworthy key is still better = from a security point of view than one that is en-clair. My consistent = suggestion has been that any browser should accept any key to start SSL = unless the user types in https:// at the command line. The only = difference being that the browser should not tell the user that SSL is = in use in primary chrome.
=0A=
 
=0A=
 
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
From: Jeffrey = Hutzelman [mailto:jhutz@cmu.edu]
Sent: Wed 2/25/2009 11:29 = AM
To: Hallam-Baker, Phillip; Stephen Kent; = saag@ietf.org
Cc: jhutz@cmu.edu
Subject: Re: [saag] = SHA-1 to SHA-n transition

=0A=
=0A=

--On Monday, February 23, 2009 11:13:55 AM -0800 = "Hallam-Baker, Phillip"
<pbaker@verisign.com> = wrote:

> Let us see, I suggest that we might need to slay a = sacred PKIX cow or two
> in order to make the SHA-n transition = work. Stephen:
> * Describes the suggestion as = 'offensive'

Yes, this sort of crack is offensive and = counterproductive.  Knock it off.

If you have a proposal to = make, then fine, make it.
Don't start off by deliberately attacking = people who you think will oppose
your proposal, on the basis of = arguments that haven't yet been made and
probably won't be.  = _That_ is offensive.

So, by the way, is the "sacred cow" = comparsion, to some folks.


Your actual proposal makes a = number of very large assumptions, such as...


- that = interactive Web browsers with access to stable storage and
  = nearly-continuous access to the connected Internet are the = only
  problem worth solving.

  Possibly true for = your company, and other CA's, and browser vendors.
  Definitely = _not_ true for the IETF.

- that because certain conditions hold = now, they always will

  Definitely not true for anyone, = outside of an extremely tightly
  controlled environment, and = maybe not even then.

- that it is OK for browser software to = silently make configuration
  changes based on external stimulus = and without the user's consent.

  This is definitely not = true, and will actively screw people if the
  browser vendors = ever implement your proposal.  Suppose you distribute
  = your so-called "suicide note", causing my browser to reconfigure = itself
  (silently and without my consent) to disallow = SHA-1.  Unfortunately,
  my entire enterprise PKI was based = on SHA-1 certificates, and you have
  just thrown my = organization into chaos, potentially costing billions
  of = dollars.  Can you imagine the lawsuits when Microsoft does this = to
  a major financial institution?  Can you imagine the = economic impact
  when Microsoft does this to _every_ major = financial institution?


-- = Jeff

------_=_NextPart_001_01C9976F.BD8EA0C2-- From SChokhani@cygnacom.com Wed Feb 25 10:54:16 2009 Return-Path: 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 8871E28C1A3 for ; Wed, 25 Feb 2009 10:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 pJSPX-bP1hwg for ; Wed, 25 Feb 2009 10:54:15 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 8F38A28C294 for ; Wed, 25 Feb 2009 10:54:14 -0800 (PST) Received: (qmail 623 invoked from network); 25 Feb 2009 18:54:21 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Feb 2009 18:54:20 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9977A.7FA3B1AD" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Feb 2009 13:54:33 -0500 Message-ID: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmXZkIHNTtGqAcDRpSQz8zKbJ8T6AAA6ulYAAPTS+A= References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu> <2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Santosh Chokhani" To: Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 18:54:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9977A.7FA3B1AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has any one seen the DSSC I-D from LTANS WG on checking for acceptable algorithms. =20 I also find that migration from SHA1 to SHA 256 will not be as painful, albeit not all spec have it and they need updating. =20 I say this because there is no pre-image attack on the horizon, changing the algorithm some time before SHA1 compromise keeps the infrastructure secure without fear of contamination. =20 I have found Phillip's OCSP argument as a solution looking for problem. When he published his first draft on this in PKIX, WG I provided him extensive comments. Many of my misgivings still remain. ________________________________ From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, February 25, 2009 12:38 PM To: Jeffrey Hutzelman; Stephen Kent; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =09 =09 As it happens, what I was referring to is that I do not like the look of this scheme. It is an ugly hack. However I dislike the consequences of not addressing this issue up front rather more and I really don't see how a less hackish solution will serve. =20 Now I did get offended by the implication that we should not consider technical issues if they might offend people. As with an earlier case where a past Security AD blocked a necessary protocol change because it 'gave him a bad gut feeling'. While making decisions based on the examination of intestines was all the rage in ancient Rome, it should be avoided. =20 =20 On the points you raise. =20 1) If a device is not connected to a communications network, then why would it need to establish a cryptographic communication security context? =20 The offline PKI argument is seductive, but when you get down to case analysis, the real purpose of PKI is to communicate. The security guarantees that are possible in the offline case will always be lower than can be achieved in the online case. =20 If the device is not connected to a network realtime then issues such as certificate status are going to be have to be handled by something that is online and can pass a satisfactory proof of trustworthiness on. =20 But in any case, the issues are entirely addressed by OCSP token stapling which is possible in SSL and S/MIME and any XML signature based protocol. =20 =20 2) 'that because certain conditions hold now, they always will' =20 I do not understand the relevance. What the claim amounts to is asserting that because my prediction of the future might be falible, no precidtion can be made, all outcomes are equally likely. =20 You base strategy on your best knowledge of the current situation and your best faith prediction of the consequences. If someone wants to challenge that analysis they should provide new facts and/or argue that different consequences are likely. =20 We have long experience of what the world does when we tell it our view of what the best thing is from a security perspective - they ignore us do what they think is in their best short term interests. =20 =20 3) 'that it is OK for browser software to silently make configuration changes based on external stimulus and without the user's consent.' =09 Here you might have a point. But I am not certain. In any case it is an implementation detail. What degree of control end users have is a policy matter. Most users are entirely happy for Microsoft or McAfee to control security on their PC. =20 Kill switches are unfortunately necessary at times. What is important is not so much the existence of the kill switch as who is in control. =20 In this particular case the whole purpose is to put enterprises and CAs on notice that a change is going to be necessary and that they have to start planning for it right now without setting a premature termination date. All an enterprise need do to plan for the transition is to upgrade their internal CA and their Web servers before SHA1 is actually broken.=20 =20 One option would be to allow the end user (or system manager) to over-ride the suicide note - provided that an equally secure mechanism was used for the control channel. Another would be to allow local configuration of the suicide note issuer. =20 I am not to sure about the consequences for your internal CA. If the roots are embedded in the browser then why not expect them to be handled according to current best practice? If the roots are not embedded then you might as well treat them as self signed certificates and allow a per-site exception. =20 I am not actually a fan of turning off certificates. An HTTP connection that is secured to an untrustworthy key is still better from a security point of view than one that is en-clair. My consistent suggestion has been that any browser should accept any key to start SSL unless the user types in https:// at the command line. The only difference being that the browser should not tell the user that SSL is in use in primary chrome. =20 =20 =20 =20 ________________________________ From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Wed 2/25/2009 11:29 AM To: Hallam-Baker, Phillip; Stephen Kent; saag@ietf.org Cc: jhutz@cmu.edu Subject: Re: [saag] SHA-1 to SHA-n transition =09 =09 --On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip" wrote: =09 > Let us see, I suggest that we might need to slay a sacred PKIX cow or two > in order to make the SHA-n transition work. Stephen: > * Describes the suggestion as 'offensive' =09 Yes, this sort of crack is offensive and counterproductive. Knock it off. =09 If you have a proposal to make, then fine, make it. Don't start off by deliberately attacking people who you think will oppose your proposal, on the basis of arguments that haven't yet been made and probably won't be. _That_ is offensive. =09 So, by the way, is the "sacred cow" comparsion, to some folks. =09 =09 Your actual proposal makes a number of very large assumptions, such as... =09 =09 - that interactive Web browsers with access to stable storage and nearly-continuous access to the connected Internet are the only problem worth solving. =09 Possibly true for your company, and other CA's, and browser vendors. Definitely _not_ true for the IETF. =09 - that because certain conditions hold now, they always will =09 Definitely not true for anyone, outside of an extremely tightly controlled environment, and maybe not even then. =09 - that it is OK for browser software to silently make configuration changes based on external stimulus and without the user's consent. =09 This is definitely not true, and will actively screw people if the browser vendors ever implement your proposal. Suppose you distribute your so-called "suicide note", causing my browser to reconfigure itself (silently and without my consent) to disallow SHA-1. Unfortunately, my entire enterprise PKI was based on SHA-1 certificates, and you have just thrown my organization into chaos, potentially costing billions of dollars. Can you imagine the lawsuits when Microsoft does this to a major financial institution? Can you imagine the economic impact when Microsoft does this to _every_ major financial institution? =09 =09 -- Jeff =09 ------_=_NextPart_001_01C9977A.7FA3B1AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n = transition
Has any one seen the DSSC I-D from LTANS = WG on=20 checking for acceptable algorithms.
 
I also find that migration from SHA1 to SHA = 256 will=20 not be as painful, albeit not all spec have it and they need=20 updating.
 
I say this because there is no pre-image = attack on the=20 horizon, changing the algorithm some time before SHA1 compromise keeps = the=20 infrastructure secure without fear of contamination.
 
I have found Phillip's OCSP argument as a = solution=20 looking for problem.  When he published his first draft on this in = PKIX,=20 WG I provided him extensive comments.  Many of my misgivings = still=20 remain.

From: saag-bounces@ietf.org=20 [mailto:saag-bounces@ietf.org] On Behalf Of Hallam-Baker,=20 Phillip
Sent: Wednesday, February 25, 2009 12:38 = PM
To:=20 Jeffrey Hutzelman; Stephen Kent; saag@ietf.org
Subject: Re: = [saag]=20 SHA-1 to SHA-n transition

As it happens, what I was referring to is that I = do not like=20 the look of this scheme. It is an ugly hack. However I dislike the=20 consequences of not addressing this issue up front rather more and I = really=20 don't see how a less hackish solution will serve.
 
Now I did get offended by the implication that we = should not=20 consider technical issues if they might offend people. As with an = earlier case=20 where a past Security AD blocked a necessary protocol change because = it 'gave=20 him a bad gut feeling'. While making decisions based on the = examination of=20 intestines was all the rage in ancient Rome, it should be = avoided.
 
 
On the points you raise.
 
1) If a device is not connected to a communications = network, then=20 why would it need to establish a cryptographic communication security=20 context?
 
The offline PKI argument is seductive, but when you get = down to=20 case analysis, the real purpose of PKI is to communicate. The security = guarantees that are possible in the offline case will always be lower = than can=20 be achieved in the online case.
 
If the device is not connected to a network realtime = then issues=20 such as certificate status are going to be have to be handled by = something=20 that is online and can pass a satisfactory proof of trustworthiness = on.
 
But in any case, the issues are entirely addressed by = OCSP token=20 stapling which is possible in SSL and S/MIME and any XML signature = based=20 protocol.
 
 
2) 'that because certain conditions hold now, they = always=20 will'
 
I do not understand the relevance. What the claim = amounts to is=20 asserting that because my prediction of the future might be falible, = no=20 precidtion can be made, all outcomes are equally likely.
 
You base strategy on your best knowledge of the current = situation=20 and your best faith prediction of the consequences. If someone wants = to=20 challenge that analysis they should provide new facts and/or = argue that=20 different consequences are likely.
 
We have long experience of what the world does when we = tell it=20 our view of what the best thing is from a security perspective - they = ignore=20 us do what they think is in their best short term = interests.
 
 
3)  'that it is OK for browser software to = silently make=20 configuration  changes based on external stimulus and without the = user's=20 consent.'
Here you might have a point. But I am not certain. In = any case it=20 is an implementation detail. What degree of control end users have is = a policy=20 matter. Most users are entirely happy for Microsoft or McAfee to = control=20 security on their PC.
 
Kill switches are unfortunately necessary at times. = What is=20 important is not so much the existence of the kill switch as who = is in=20 control.
 
In this particular case the whole purpose is to put = enterprises=20 and CAs on notice that a change is going to be necessary and that they = have to=20 start planning for it right now without setting a premature = termination date.=20 All an enterprise need do to plan for the transition is to upgrade = their=20 internal CA and their Web servers before SHA1 is actually broken. =
 
One option would be to allow the end user (or system = manager) to=20 over-ride the suicide note - provided that an equally secure mechanism = was=20 used for the control channel. Another would be to allow local = configuration of=20 the suicide note issuer.
 
I am not to sure about the consequences for your = internal CA. If=20 the roots are embedded in the browser then why not expect them to be = handled=20 according to current best practice? If the roots are not embedded then = you=20 might as well treat them as self signed certificates and allow a=20 per-site exception.
 
I am not actually a fan of turning off certificates. An = HTTP=20 connection that is secured to an untrustworthy key is still better = from a=20 security point of view than one that is en-clair. My consistent = suggestion has=20 been that any browser should accept any key to start SSL unless the = user types=20 in https:// at the command line. The only difference being that the = browser=20 should not tell the user that SSL is in use in primary chrome.
 
 
 
 
From: Jeffrey = Hutzelman=20 [mailto:jhutz@cmu.edu]
Sent: Wed 2/25/2009 11:29 = AM
To:=20 Hallam-Baker, Phillip; Stephen Kent; saag@ietf.org
Cc:=20 jhutz@cmu.edu
Subject: Re: [saag] SHA-1 to SHA-n=20 transition

--On Monday, February 23, 2009 11:13:55 AM -0800=20 "Hallam-Baker, Phillip"
<pbaker@verisign.com> = wrote:

> Let=20 us see, I suggest that we might need to slay a sacred PKIX cow or = two
>=20 in order to make the SHA-n transition work. Stephen:
> * = Describes the=20 suggestion as 'offensive'

Yes, this sort of crack is offensive = and=20 counterproductive.  Knock it off.

If you have a proposal = to make,=20 then fine, make it.
Don't start off by deliberately attacking = people who=20 you think will oppose
your proposal, on the basis of arguments that = haven't=20 yet been made and
probably won't be.  _That_ is = offensive.

So,=20 by the way, is the "sacred cow" comparsion, to some = folks.


Your=20 actual proposal makes a number of very large assumptions, such=20 as...


- that interactive Web browsers with access to stable = storage=20 and
  nearly-continuous access to the connected Internet are = the=20 only
  problem worth solving.

  Possibly true for = your=20 company, and other CA's, and browser vendors.
  Definitely = _not_ true=20 for the IETF.

- that because certain conditions hold now, they = always=20 will

  Definitely not true for anyone, outside of an = extremely=20 tightly
  controlled environment, and maybe not even = then.

-=20 that it is OK for browser software to silently make = configuration
 =20 changes based on external stimulus and without the user's=20 consent.

  This is definitely not true, and will actively = screw=20 people if the
  browser vendors ever implement your = proposal. =20 Suppose you distribute
  your so-called "suicide note", = causing my=20 browser to reconfigure itself
  (silently and without my = consent) to=20 disallow SHA-1.  Unfortunately,
  my entire enterprise = PKI was=20 based on SHA-1 certificates, and you have
  just thrown my=20 organization into chaos, potentially costing billions
  of=20 dollars.  Can you imagine the lawsuits when Microsoft does this=20 to
  a major financial institution?  Can you imagine the = economic=20 impact
  when Microsoft does this to _every_ major financial=20 institution?


-- = Jeff

------_=_NextPart_001_01C9977A.7FA3B1AD-- From mouse@Sparkle.Rodents-Montreal.ORG Wed Feb 25 11:51:40 2009 Return-Path: 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 75A2228C188 for ; Wed, 25 Feb 2009 11:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.351 X-Spam-Level: X-Spam-Status: No, score=-8.351 tagged_above=-999 required=5 tests=[AWL=1.637, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 UlgzsGi6E5LX for ; Wed, 25 Feb 2009 11:51:39 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 146F328C2A4 for ; Wed, 25 Feb 2009 11:51:38 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA23103; Wed, 25 Feb 2009 14:51:42 -0500 (EST) From: der Mouse Message-Id: <200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 25 Feb 2009 14:46:47 -0500 (EST) To: saag@ietf.org In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu> <5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu> <2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:51:40 -0000 > As with an earlier case where a past Security AD blocked a necessary > protocol change because it 'gave him a bad gut feeling'. While > making decisions based on the examination of intestines was all the > rage in ancient Rome, it should be avoided. I don't know the particular case you're talking about, nor do I really want to, so I specifically want to avoid commenting on that case. But I would hesitate to summarily write off the gut feeling of someone experienced, which is more or less what I read your second sentence as; much of what experience _is_ amounts to training one's gut feeling. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pbaker@verisign.com Wed Feb 25 14:02:09 2009 Return-Path: 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 55EDF3A6912 for ; Wed, 25 Feb 2009 14:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 d0QCRm5wFrE3 for ; Wed, 25 Feb 2009 14:02:08 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E72313A68E4 for ; Wed, 25 Feb 2009 14:02:07 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1PLc7u9018661; Wed, 25 Feb 2009 13:38:07 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 14:02:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99794.BF3D2A56" Date: Wed, 25 Feb 2009 14:02:27 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmXg1Y7xVXyrzTlS+6/sU1/NXLwuQAD5SAr References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> <200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> From: "Hallam-Baker, Phillip" To: "der Mouse" , X-OriginalArrivalTime: 25 Feb 2009 22:02:28.0178 (UTC) FILETIME=[BF929B20:01C99794] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:02:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99794.BF3D2A56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have a choice here. =20 Either we have a debate in which people bring up rational technical = points or we have a free for all in which people claim a privileged = position that allows them to block any proposed change to the status quo = without giving a technical reason that can be challeged. =20 My gut is telling me that we have a very serious problem that is going = to bite us down the road. And I can give solid technical reasons to back = that feeling. =20 We have the same set of arguments whenever someone suggests that the = IETF consider practical deployment issues. It is never the right time to = raise these issues and they are never raised in the right way. =20 =20 Let us stick to the technical issues here: =20 * Is the current transition plan viable or does it fail in the way that = I predict * Is the proposed solution viable? * Is there a better solution? =20 =20 ________________________________ From: saag-bounces@ietf.org on behalf of der Mouse Sent: Wed 2/25/2009 2:46 PM To: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition > As with an earlier case where a past Security AD blocked a necessary > protocol change because it 'gave him a bad gut feeling'. While > making decisions based on the examination of intestines was all the > rage in ancient Rome, it should be avoided. I don't know the particular case you're talking about, nor do I really want to, so I specifically want to avoid commenting on that case. But I would hesitate to summarily write off the gut feeling of someone experienced, which is more or less what I read your second sentence as; much of what experience _is_ amounts to training one's gut feeling. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99794.BF3D2A56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
We have a = choice here.
=0A=
 
=0A=
Either we have a debate in = which people bring up rational technical points or we have a free for = all in which people claim a privileged position that allows them to = block any proposed change to the status quo without giving a technical = reason that can be challeged.
=0A=
 
=0A=
My gut is telling me that we = have a very serious problem that is going to bite us down the road. And = I can give solid technical reasons to back that feeling.
=0A=
 
=0A=
We have the same set of = arguments whenever someone suggests that the IETF consider practical = deployment issues. It is never the right time to raise these issues and = they are never raised in the right way.
=0A=
 
=0A=
 
=0A=
Let us stick to the technical = issues here:
=0A=
 
=0A=
* Is the current transition = plan viable or does it fail in the way that I predict
=0A=
* Is the proposed solution = viable?
=0A=
* Is there a better = solution?
=0A=
 
=0A=
 
=0A=
=0A=

=0A=
=0A=
=0A=
=0A=
From: = saag-bounces@ietf.org on behalf of der Mouse
Sent: Wed = 2/25/2009 2:46 PM
To: saag@ietf.org
Subject: Re: = [saag] SHA-1 to SHA-n transition

=0A=
=0A=

> As with an earlier case where a past Security AD = blocked a necessary
> protocol change because it 'gave him a bad = gut feeling'.  While
> making decisions based on the = examination of intestines was all the
> rage in ancient Rome, it = should be avoided.

I don't know the particular case you're = talking about, nor do I really
want to, so I specifically want to = avoid commenting on that case.  But
I would hesitate to = summarily write off the gut feeling of someone
experienced, which is = more or less what I read your second sentence as;
much of what = experience _is_ amounts to training one's gut feeling.

/~\ The = ASCII           =         =           Mouse
\ / Ribbon = Campaign
 X  Against = HTML        =         = mouse@rodents-montreal.org
/ \ Email!      =      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 = 27 4B
_______________________________________________
saag mailing = list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C99794.BF3D2A56-- From paul.hoffman@vpnc.org Wed Feb 25 14:43:17 2009 Return-Path: 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 B7DA53A68CB for ; Wed, 25 Feb 2009 14:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] 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 9e8Vv2c9vThR for ; Wed, 25 Feb 2009 14:43:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9E8C23A6A9C for ; Wed, 25 Feb 2009 14:43:16 -0800 (PST) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1PMhYSW003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Feb 2009 15:43:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> References: <200902231914.n1NJEDA3011916@raisinb ran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><27884 66ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com> <200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Wed, 25 Feb 2009 14:43:33 -0800 To: From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:43:18 -0000 At 2:02 PM -0800 2/25/09, Hallam-Baker, Phillip wrote: >Let us stick to the technical issues here: > >* Is the current transition plan viable or does it fail in the way that I predict >* Is the proposed solution viable? >* Is there a better solution? None of those are technical issues. --Paul Hoffman, Director --VPN Consortium From ietfdbh@comcast.net Wed Feb 25 15:19:23 2009 Return-Path: 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 6130C3A6BA1 for ; Wed, 25 Feb 2009 15:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GpMoL07wSfJD for ; Wed, 25 Feb 2009 15:19:22 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 7A2503A6AE6 for ; Wed, 25 Feb 2009 15:19:22 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id LKWj1b00X1HzFnQ55PKkdV; Wed, 25 Feb 2009 23:19:44 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id LPKj1b00N0UQ6dC3aPKjEk; Wed, 25 Feb 2009 23:19:44 +0000 From: "David Harrington" To: "'Hallam-Baker, Phillip'" , "'der Mouse'" , References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com><200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Wed, 25 Feb 2009 18:19:42 -0500 Message-ID: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C24_01C99775.A146CF70" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmXg1Y7xVXyrzTlS+6/sU1/NXLwuQAD5SArAAMRyZA= Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:19:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0C24_01C99775.A146CF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I find it rich that you started this thread by being offensive, and now you want " Let us stick to the technical issues here: If you want people to listen to you and discuss technical arguments, maybe you should learn to introduce the topics in a less offensive manner. If people do not want to have this discussion with you at this time, you have only yourself to blame. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0C24_01C99775.A146CF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n = transition
Hi,
 
I find it rich that you started this thread by = being=20 offensive, and now you want
"
Let us stick to the = technical issues=20 here:
 
If you want people to listen to you and discuss technical = arguments,=20 maybe you should learn to introduce the topics in a less offensive=20 manner.
 
If people do not want to have this discussion with you at = this time,=20 you have only yourself to blame.
 

David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

------=_NextPart_000_0C24_01C99775.A146CF70-- From Nicolas.Williams@sun.com Wed Feb 25 15:33:52 2009 Return-Path: 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 6D72E3A69DE for ; Wed, 25 Feb 2009 15:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, 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 dFBdbuaK55jM for ; Wed, 25 Feb 2009 15:33:51 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 6880028C2E8 for ; Wed, 25 Feb 2009 15:33:36 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1PNXsXM004513 for ; Wed, 25 Feb 2009 23:33:55 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 n1PNXsPL024895 for ; Wed, 25 Feb 2009 16:33:54 -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 n1PNOuXE008298; Wed, 25 Feb 2009 17:24:56 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1PNOteU008297; Wed, 25 Feb 2009 17:24:55 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Feb 2009 17:24:55 -0600 From: Nicolas Williams To: "Hallam-Baker, Phillip" Message-ID: <20090225232455.GZ9992@Sun.COM> References: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> <2788466ED3E31C418E9ACC5C3166155768B2B8@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2B8@mou1wnexmb09.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:33:52 -0000 On Fri, Feb 20, 2009 at 11:06:31AM -0800, Hallam-Baker, Phillip wrote: > Should probably raise awareness of the fact that the SHA1-to SHA-n > algorithm transition is not going to look anything like the MD5-SHA1 > transition. > > The MD5 to SHA1 transition was relatively painless because almost > every cryptographic protocol that supported one also supported the > other. In the mid 1990s the fashion was to have redundant algorithms > and MD5 and SHA1 came out round about the same time. In particular > every browser that supported SSL 2.0 was required to support both. Well, not really. Lots of protocols only had MD5 or worse. What helped the MD5->SHA-1 transition was that it happened over many years. The same is likely to be true of the SHA-1->SHA-n transition. > If we start addressing the problem now we can lay ourselves an > insurance policy. If we try to insist on the pristine principles of > the PKIX infrastructure we are going to be in deep trouble in about > five years time. That was a non-sequitur, and many have complained, but sure, I can ignore it (web apps and browsers never really held to "the pristine principles of the PKIX infrastructure" -- there has never been a real PKI for browser apps -- thus your comment is not even technically correct). So what's your proposal? The suicide note thing? Nico -- From pbaker@verisign.com Wed Feb 25 17:23:05 2009 Return-Path: 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 C0E353A69C4 for ; Wed, 25 Feb 2009 17:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 k2cGMj1GfFOG for ; Wed, 25 Feb 2009 17:23:04 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E09913A6872 for ; Wed, 25 Feb 2009 17:23:04 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1Q0x2Ge026382; Wed, 25 Feb 2009 16:59:02 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 17:23:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C997B0.D11CF7E2" Date: Wed, 25 Feb 2009 17:23:23 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2CD@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Request for agenda items Thread-Index: AcmXopS8L1JxYbgcTMqlgXEiVJzpZgADGaS3 References: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> <2788466ED3E31C418E9ACC5C3166155768B2B8@mou1wnexmb09.vcorp.ad.vrsn.com> <20090225232455.GZ9992@Sun.COM> From: "Hallam-Baker, Phillip" To: "Nicolas Williams" X-OriginalArrivalTime: 26 Feb 2009 01:23:24.0648 (UTC) FILETIME=[D1C9EE80:01C997B0] Cc: saag@ietf.org Subject: Re: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:23:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C997B0.D11CF7E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well yes and no. Agreed that a lot of protocols have a lot more Md5 in = than we would wish. But SSL had a fairly strong tow and tended to pull = SHA1 along with it. =20 And, yes I agree that practice of cryptography has been much more = pragmatic than pristine. Only that tended to be what we did after = exhausting all the other alternatives. =20 =20 I am not sure I have an alternative yet. I have one possible way to = solve the problem. There might be a better way. =20 ________________________________ From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] Sent: Wed 2/25/2009 6:24 PM To: Hallam-Baker, Phillip Cc: saag@ietf.org Subject: Re: [saag] Request for agenda items On Fri, Feb 20, 2009 at 11:06:31AM -0800, Hallam-Baker, Phillip wrote: > Should probably raise awareness of the fact that the SHA1-to SHA-n > algorithm transition is not going to look anything like the MD5-SHA1 > transition. >=20 > The MD5 to SHA1 transition was relatively painless because almost > every cryptographic protocol that supported one also supported the > other. In the mid 1990s the fashion was to have redundant algorithms > and MD5 and SHA1 came out round about the same time. In particular > every browser that supported SSL 2.0 was required to support both. Well, not really. Lots of protocols only had MD5 or worse. What helped the MD5->SHA-1 transition was that it happened over many years. The same is likely to be true of the SHA-1->SHA-n transition. > If we start addressing the problem now we can lay ourselves an > insurance policy. If we try to insist on the pristine principles of > the PKIX infrastructure we are going to be in deep trouble in about > five years time. That was a non-sequitur, and many have complained, but sure, I can ignore it (web apps and browsers never really held to "the pristine principles of the PKIX infrastructure" -- there has never been a real PKI for browser apps -- thus your comment is not even technically correct). So what's your proposal? The suicide note thing? Nico -- ------_=_NextPart_001_01C997B0.D11CF7E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] Request for agenda items=0A= =0A= =0A= =0A=
=0A=
Well yes and = no. Agreed that a lot of protocols have a lot more Md5 in than we would = wish. But SSL had a fairly strong tow and tended to pull SHA1 along with = it.
=0A=
 
=0A=
And, yes I agree that = practice of cryptography has been much more pragmatic than pristine. = Only that tended to be what we did after exhausting all the other = alternatives.
=0A=
 
=0A=
 
=0A=
I am not sure I have an = alternative yet. I have one possible way to solve the problem. There = might be a better way.
=0A=
 
=0A=
=0A=

=0A=
=0A=
=0A=
=0A=
From: Nicolas = Williams [mailto:Nicolas.Williams@sun.com]
Sent: Wed 2/25/2009 = 6:24 PM
To: Hallam-Baker, Phillip
Cc: = saag@ietf.org
Subject: Re: [saag] Request for agenda = items

=0A=
=0A=

On Fri, Feb 20, 2009 at 11:06:31AM -0800, = Hallam-Baker, Phillip wrote:
> Should probably raise awareness of = the fact that the SHA1-to SHA-n
> algorithm transition is not = going to look anything like the MD5-SHA1
> = transition.
> 
> The MD5 to SHA1 transition was = relatively painless because almost
> every cryptographic protocol = that supported one also supported the
> other. In the mid 1990s = the fashion was to have redundant algorithms
> and MD5 and SHA1 = came out round about the same time. In particular
> every browser = that supported SSL 2.0 was required to support both.

Well, not = really.  Lots of protocols only had MD5 or worse.  What = helped
the MD5->SHA-1 transition was that it happened over many = years.  The
same is likely to be true of the SHA-1->SHA-n = transition.

> If we start addressing the problem now we can = lay ourselves an
> insurance policy. If we try to insist on the = pristine principles of
> the PKIX infrastructure we are going to = be in deep trouble in about
> five years time.

That was a = non-sequitur, and many have complained, but sure, I can
ignore it = (web apps and browsers never really held to "the pristine
principles = of the PKIX infrastructure" -- there has never been a real
PKI for = browser apps -- thus your comment is not even = technically
correct).

So what's your proposal?  The = suicide note thing?

Nico
--

------_=_NextPart_001_01C997B0.D11CF7E2-- From pbaker@verisign.com Wed Feb 25 17:34:45 2009 Return-Path: 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 DA40B3A6A9C for ; Wed, 25 Feb 2009 17:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 U86Ub0D+bFR6 for ; Wed, 25 Feb 2009 17:34:44 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E043A3A69C3 for ; Wed, 25 Feb 2009 17:34:44 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1Q1AiDu026753; Wed, 25 Feb 2009 17:10:44 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 17:35:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C997B2.732D57BE" Date: Wed, 25 Feb 2009 17:35:04 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmXg1Y7xVXyrzTlS+6/sU1/NXLwuQAD5SArAAMRyZAABDIfaA== References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com><200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> From: "Hallam-Baker, Phillip" To: "David Harrington" , "der Mouse" , X-OriginalArrivalTime: 26 Feb 2009 01:35:06.0249 (UTC) FILETIME=[73F9BF90:01C997B2] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:34:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C997B2.732D57BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was intending to raise a serious technical point. If the comment might = have been interpreted as offensive it is because it might be interpeted = as a suggestion that people would be more interested in debating a = distraction than the technical issue.=20 =20 =20 Can we please stop the agenda denial tactics and talk about the fact = that we may have a serious problem? =20 Currently the industry is taking for granted the idea that merely = distributng browsers that support stronger crypto algorithms is = sufficient to support a transition when that becomes necessary. But when = serious attention is paid to the business issues that drive the purchase = of certificates it is clear that this strategy is not going to result in = the withdrawal of support for SHA1 certificates until the population of = browsers that support only SHA1 is negligible. That will take at least a = decade, possibly much longer. =20 If people really think that Amazon.com is going to say 'I know that only = 95% of browsers support SHA1, but I am going to get an SHA2 cert and = lose that 5% of sales so that our transactions are as secure as = possible' because someone finds a practical attack on SHA1, then let = them say that. So far nobody has challenged the analysis directly, they = have merely described themselves as unconvinced that there is a problem. =20 =20 =20 ________________________________ From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wed 2/25/2009 6:19 PM To: Hallam-Baker, Phillip; 'der Mouse'; saag@ietf.org Subject: RE: [saag] SHA-1 to SHA-n transition Hi, =20 I find it rich that you started this thread by being offensive, and now = you want " Let us stick to the technical issues here: =20 If you want people to listen to you and discuss technical arguments, = maybe you should learn to introduce the topics in a less offensive = manner. =20 If people do not want to have this discussion with you at this time, = you have only yourself to blame. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ------_=_NextPart_001_01C997B2.732D57BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
I was intending to raise a = serious technical point. If the comment might have been interpreted as = offensive it is because it might be interpeted as a suggestion = that people would be more interested in debating a distraction than the = technical issue.
=0A=
 
=0A=
 
=0A=
Can we please stop the agenda = denial tactics and talk about the fact that we may have a serious = problem?
=0A=
 
=0A=
Currently the industry is = taking for granted the idea that merely distributng browsers that = support stronger crypto algorithms is sufficient to support a transition = when that becomes necessary. But when serious attention is paid to the = business issues that drive the purchase of certificates it is clear that = this strategy is not going to result in the withdrawal of support for = SHA1 certificates until the population of browsers that support only = SHA1 is negligible. That will take at least a decade, possibly much = longer.
=0A=
 
=0A=
If people really think that = Amazon.com is going to say 'I know that only 95% of browsers support = SHA1, but I am going to get an SHA2 cert and lose that 5% of sales so = that our transactions are as secure as possible' because someone finds a = practical attack on SHA1, then let them say that. So far nobody has = challenged the analysis directly, they have merely described themselves = as unconvinced that there is a problem.
=0A=
 
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: David Harrington = [mailto:ietfdbh@comcast.net]
Sent: Wed 2/25/2009 6:19 = PM
To: Hallam-Baker, Phillip; 'der Mouse'; = saag@ietf.org
Subject: RE: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=
Hi,
=0A=
 
=0A=
I find it rich that you started = this thread by being offensive, and now you want
=0A=
"
=0A=
=0A=
=0A=
Let us stick to the technical = issues here:
=0A=
 
=0A=
If you want people to listen to you and discuss = technical arguments, maybe you should learn to introduce the topics in a = less offensive manner.
=0A=
 
=0A=
If people do not want to have this discussion = with you at this time, you have only yourself to = blame.
=0A=
 
=0A=
=0A=

David = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

------_=_NextPart_001_01C997B2.732D57BE-- From onq@indigo.ie Thu Feb 26 02:51:26 2009 Return-Path: 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 B34BD3A69DC for ; Thu, 26 Feb 2009 02:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_LWSHORTT=1.24] 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 7IAaZcgJ0mdS for ; Thu, 26 Feb 2009 02:51:26 -0800 (PST) Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by core3.amsl.com (Postfix) with SMTP id C82893A696D for ; Thu, 26 Feb 2009 02:51:25 -0800 (PST) Received: (qmail 37920 messnum 9358179 invoked from network[86.43.216.88/86-43-216-88-dynamic.b-ras2.bbh.dublin.eircom.net]); 26 Feb 2009 10:51:46 -0000 Received: from 86-43-216-88-dynamic.b-ras2.bbh.dublin.eircom.net (HELO ?192.168.1.68?) (86.43.216.88) by mail13.svc.cra.dublin.eircom.net (qp 37920) with SMTP; 26 Feb 2009 10:51:46 -0000 Message-ID: <49A67336.1020501@indigo.ie> Date: Thu, 26 Feb 2009 10:47:18 +0000 From: Michael O'Neill User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Harrington References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com><200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG> <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> In-Reply-To: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'der Mouse' , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:51:26 -0000 David Harrington wrote:
Re: [saag] SHA-1 to SHA-n transition
Hi,
 
I find it rich that you started this thread by being offensive, and now you want
"
Let us stick to the technical issues here:
 
If you want people to listen to you and discuss technical arguments, maybe you should learn to introduce the topics in a less offensive manner.
 
If people do not want to have this discussion with you at this time, you have only yourself to blame.
 

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

Focus furthers aims.
Short term focus fails long term.
'Ware the focus freaks.

Michael O'Neill
From tytso@mit.edu Thu Feb 26 06:38:05 2009 Return-Path: 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 78A9E28C2E3 for ; Thu, 26 Feb 2009 06:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, IP_NOT_FRIENDLY=0.334] 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 xgGR+qZwU0go for ; Thu, 26 Feb 2009 06:38:04 -0800 (PST) Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 0289428C2E2 for ; Thu, 26 Feb 2009 06:37:53 -0800 (PST) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LchNL-0007nm-Cg; Thu, 26 Feb 2009 09:38:11 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LchNJ-0003Za-Sb; Thu, 26 Feb 2009 09:38:09 -0500 Date: Thu, 26 Feb 2009 09:38:09 -0500 From: Theodore Tso To: "Hallam-Baker, Phillip" Message-ID: <20090226143809.GF7227@mit.edu> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 14:38:05 -0000 On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote: > > If people really think that Amazon.com is going to say 'I know that > only 95% of browsers support SHA1, but I am going to get an SHA2 > cert and lose that 5% of sales so that our transactions are as > secure as possible' because someone finds a practical attack on > SHA1, then let them say that. So far nobody has challenged the > analysis directly, they have merely described themselves as > unconvinced that there is a problem. > OK, so let's get real here. The reality is that transitioning between crypto algorithms is *hard*, and that the tragedy of the commons is hitting us hard. We can try to create technical solutions (such as the Svengali-style suicide note which causes browsers to break intranets), but their have shortcomings because this is fundamentally a social problem. There are couple of things we need to do in order to successfully carry off a migration: (1) We need to get browsers to add support for the new crypto algorithm (2) We need to get users to upgrade to the new browsers with support for the new crypto algorithm (3) Once (1) and (2) are done, we need to get secure commerce sites to upgrade to use certificates that utilize the new crypto algorithm. (In practice this will be the crypto checksum; but the same thing applies if we ever need to get nervous about replacing the PK algorithm.) This normally takes time --- years, but it is possible to speed things up. For example, an interested body, perhaps funded by far-sighted merchants and other concerned citizens, could track which browsers have added the new algorithms, and jawbone (and perhaps in the later part of the effort, publically shame) entities distributing browsers to implement the new algorithm. For (2), sites who were interested in being "good citizens" could test to see if the browser supports the new crypto algorithm, and display a "nag screen" if the browser apparently doesn't support the new crypto algorithm. Said nag message could be gentle at first, but could get increasingly strident; a lot of this would be up to the web site(s) involved, of course. So it's possible to encourage the ecosystem to move in a particular way, but it all requires effort and coordination, and the tragedy of the commons is that until the emergency comes up, it's unlikely that such an effort will get funding and support. But again, this is all nothing new, and I suspect one of the reasons why we're thrashing a little in this discussion is because it really is much more of a social problem than a technical problem, which means it's a bit outside of the IETF's core competency. - Ted From pbaker@verisign.com Thu Feb 26 07:33:12 2009 Return-Path: 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 3F7093A6BF6 for ; Thu, 26 Feb 2009 07:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.872 X-Spam-Level: X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 fSUueXk3zmzZ for ; Thu, 26 Feb 2009 07:33:10 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 74DDD3A6C03 for ; Thu, 26 Feb 2009 07:33:01 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QFXMiv020794; Thu, 26 Feb 2009 07:33:22 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 07:33:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99827.8E5140EA" Date: Thu, 26 Feb 2009 07:33:21 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2D2@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deployment Deadlock Thread-Index: AcmYH9sURUVD4BchSiSzrk0/zbdjzQAABw37 References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> From: "Hallam-Baker, Phillip" To: "Theodore Tso" X-OriginalArrivalTime: 26 Feb 2009 15:33:22.0664 (UTC) FILETIME=[8EF99E80:01C99827] Cc: der Mouse , saag@ietf.org Subject: [saag] Deployment Deadlock X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:33:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99827.8E5140EA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted, =20 Thanks for the comments. =20 I agree that this is really hard, but I do not think that tragedy of the = commons is a good analogy. This is not a resource depletion issue. This = is more like a prisoner's dilema issue in which following their own best = short term interests causes everyone to end up with a worst-case result. = Unlike the Axelrod prisoner's dilema, the problem does not go away when = the game is played repeatedly. On the contrary the deadlock becomes = tighter. =20 The reason that this is our problem is that the standards establish the = set of options available to the parties and the values of the outcomes. =20 The good part is that if we can understand this issue and work out a = systematic theory of how to address it we have a key that can unlock the = deployment of other protocols - IPv6, ubiquitous IPSec, ubiquitous email = encryption and so on. =20 =20 We have encountered deployment deadlock in various forms in many = different protocols. We have a lot of experience of deployment deadlock = but no systematic theory. I think that we can develop an adequate theory = for the purposes of protocol design by borrowing some ideas from the = economists, in particular rational choice theory. =20 In rational choice theory we model the behavior of each party by = *assuming* that they will follow their exclusive best interests.=20 =20 I emphasize the word assume here as it is merely a modelling assumption = and not a factual claim or a normative ethic. I do not want to get into = a distraction about whether the Rat Choice modelling assumption is a = normative truth. We are merely using it here as a modelling assumption, = we do not need to enter into a politcal digression. While it is very = clear that some people act from altruistic motives on some occasions, = and we could model this, it is necessary to assume an improbable degree = of altruism to affect the outcome. =20 =20 What I did was to identify the parties: =20 1) Web browser providers 2) Certificate Authorities 3) Merchants =20 I am using merchants as a subset of certificate holders to simplify = matters. While it may be argued that other certificate users will behave = differently, the merchants are a large enough subset that their actions = are sufficient to determine the behavior of the CAs. =20 Note that these parties are listed in a particular order. The IETF has = the greatest ability to communicate with the Web browser providers, = somewhat less contact with CAs and has negligible contact with the = merchants. As a pragmatic matter it is much easier to change IETF specs = than to mount an Al Gore publicity campaign telling folk to move to = SHA-n. And in any case we have a very limited amount of jawboning = bandwidth and we have to use that as a last resort. I would much rather = have Vint Cerf jawboning carriers into support for IPv6. =20 >From a business perspective, the actions are determined in the reverse = order. The CAs are driven by the demands of their customers. If any CA = attempts to behave altruistically by refusing to supply a product = demanded by the merchants they will lose business. In practice the = actions of the Web browser providers are driven by the facts on the = ground in the same way. =20 The facts on the ground in question are =20 1) The amount of business that merchants receive from browsers that do = not support SHA-n 2) The number of merchants who deploy SHA-n certificates =20 We have some influence on the first factor but almost no influence on = the second. At this point it is reasonably clear that the browser = providers are either supporting SHA2 today or will do so in the very = very near future. If not they risk public shame every time RSA and = Crypto come round. =20 My problem is that based on my experience of the merchants, I cannot see = any merchant voluntarily chosing a SHA-n certificate that provides only = (100-x)% coverage while there is a SHA-1 certificate on offer that gives = 100% for values of x greater than 2. No business is going to voluntarily = sacrifice even 1% of sales for a security issue that only affects the = credit card issuers. =20 And there is no way for the browser providers to withdraw support for = SHA1 if 90% or more of merchants are using SHA1 certs. Not without = proof-positive that an actual break has occured which by definition = means that we are too late. And even then it will take several years for = the SHA1 capable browsers to be withdrawn from service and those will = still be vulnerable in the interim. =20 =20 That is a deployment deadlock. =20 =20 ________________________________ From: Theodore Tso [mailto:tytso@mit.edu] Sent: Thu 2/26/2009 9:38 AM To: Hallam-Baker, Phillip Cc: David Harrington; der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote: >=20 > If people really think that Amazon.com is going to say 'I know that > only 95% of browsers support SHA1, but I am going to get an SHA2 > cert and lose that 5% of sales so that our transactions are as > secure as possible' because someone finds a practical attack on > SHA1, then let them say that. So far nobody has challenged the > analysis directly, they have merely described themselves as > unconvinced that there is a problem. >=20 OK, so let's get real here. The reality is that transitioning between crypto algorithms is *hard*, and that the tragedy of the commons is hitting us hard. We can try to create technical solutions (such as the Svengali-style suicide note which causes browsers to break intranets), but their have shortcomings because this is fundamentally a social problem. There are couple of things we need to do in order to successfully carry off a migration: (1) We need to get browsers to add support for the new crypto algorithm (2) We need to get users to upgrade to the new browsers with support for the new crypto algorithm (3) Once (1) and (2) are done, we need to get secure commerce sites to upgrade to use certificates that utilize the new crypto = algorithm. (In practice this will be the crypto checksum; but the same = thing applies if we ever need to get nervous about replacing the PK algorithm.) This normally takes time --- years, but it is possible to speed things up. For example, an interested body, perhaps funded by far-sighted merchants and other concerned citizens, could track which browsers have added the new algorithms, and jawbone (and perhaps in the later part of the effort, publically shame) entities distributing browsers to implement the new algorithm. For (2), sites who were interested in being "good citizens" could test to see if the browser supports the new crypto algorithm, and display a "nag screen" if the browser apparently doesn't support the new crypto algorithm. Said nag message could be gentle at first, but could get increasingly strident; a lot of this would be up to the web site(s) involved, of course. So it's possible to encourage the ecosystem to move in a particular way, but it all requires effort and coordination, and the tragedy of the commons is that until the emergency comes up, it's unlikely that such an effort will get funding and support.=20 But again, this is all nothing new, and I suspect one of the reasons why we're thrashing a little in this discussion is because it really is much more of a social problem than a technical problem, which means it's a bit outside of the IETF's core competency. - Ted ------_=_NextPart_001_01C99827.8E5140EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
Ted,
=0A=
 
=0A=
Thanks for the = comments.
=0A=
 
=0A=
I agree that this is really = hard, but I do not think that tragedy of the commons is a good analogy. = This is not a resource depletion issue. This is more like a prisoner's = dilema issue in which following their own best short term interests = causes everyone to end up with a worst-case result. Unlike the Axelrod = prisoner's dilema, the problem does not go away when the game is played = repeatedly. On the contrary the deadlock becomes tighter.
=0A=
 
=0A=
The reason that this is our = problem is that the standards establish the set of options available to = the parties and the values of the outcomes.
=0A=
 
=0A=
The good part is that if we = can understand this issue and work out a systematic theory of how to = address it we have a key that can unlock the deployment of other = protocols - IPv6, ubiquitous IPSec, ubiquitous email encryption and so = on.
=0A=
 
=0A=
 
=0A=
We have encountered = deployment deadlock in various forms in many different protocols. We = have a lot of experience of deployment deadlock but no systematic = theory. I think that we can develop an adequate theory for the purposes = of protocol design by borrowing some ideas from the economists, in = particular rational choice theory.
=0A=
 
=0A=
In rational choice theory we = model the behavior of each party by *assuming* that they will follow = their exclusive best interests.
=0A=
 
=0A=
I emphasize the word assume = here as it is merely a modelling assumption and not a factual claim or a = normative ethic. I do not want to get into a distraction about = whether the Rat Choice modelling assumption is a normative = truth. We are merely using it here as a modelling assumption, we do = not need to enter into a politcal digression. While it is very clear = that some people act from altruistic motives on some occasions, and we = could model this, it is necessary to assume an improbable degree of = altruism to affect the outcome.
=0A=
 
=0A=
 
=0A=
What I did was to identify = the parties:
=0A=
 
=0A=
1) Web browser = providers
=0A=
2) Certificate = Authorities
=0A=
3) Merchants
=0A=
 
=0A=
I am using merchants as a = subset of certificate holders to simplify matters. While it may be = argued that other certificate users will behave differently, the = merchants are a large enough subset that their actions are sufficient to = determine the behavior of the CAs.
=0A=
 
=0A=
Note that these parties are = listed in a particular order. The IETF has the greatest ability to = communicate with the Web browser providers, somewhat less contact with = CAs and has negligible contact with the merchants. As a pragmatic matter = it is much easier to change IETF specs than to mount an Al Gore = publicity campaign telling folk to move to SHA-n. And in any case we = have a very limited amount of jawboning bandwidth and we have to use = that as a last resort. I would much rather have Vint Cerf jawboning = carriers into support for IPv6.
=0A=
 
=0A=
From a business perspective, = the actions are determined in the reverse order. The CAs are driven by = the demands of their customers. If any CA attempts to behave = altruistically by refusing to supply a product demanded by the merchants = they will lose business. In practice the actions of the Web browser = providers are driven by the facts on the ground in the same = way.
=0A=
 
=0A=
The facts on the ground in = question are
=0A=
 
=0A=
1) The amount of business = that merchants receive from browsers that do not support = SHA-n
=0A=
2) The number of merchants = who deploy SHA-n certificates
=0A=
 
=0A=
We have some influence on the = first factor but almost no influence on the second. At this point it is = reasonably clear that the browser providers are either supporting SHA2 = today or will do so in the very very near future. If not they risk = public shame every time RSA and Crypto come round.
=0A=
 
=0A=
My problem is that based on = my experience of the merchants, I cannot see any merchant voluntarily = chosing a SHA-n certificate that provides only (100-x)% = coverage while there is a SHA-1 certificate on offer that gives = 100% for values of x greater than 2. No business is going to voluntarily = sacrifice even 1% of sales for a security issue that only affects = the credit card issuers.
=0A=
 
=0A=
And there is no way for the = browser providers to withdraw support for SHA1 if 90% or more of = merchants are using SHA1 certs. Not without proof-positive that an = actual break has occured which by definition means that we are too late. = And even then it will take several years for the SHA1 capable browsers = to be withdrawn from service and those will still be vulnerable in the = interim.
=0A=
 
=0A=
 
=0A=
That is a deployment = deadlock.
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
From: Theodore Tso = [mailto:tytso@mit.edu]
Sent: Thu 2/26/2009 9:38 = AM
To: Hallam-Baker, Phillip
Cc: David Harrington; = der Mouse; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n = transition

=0A=
=0A=

On Wed, Feb 25, 2009 at 05:35:04PM -0800, = Hallam-Baker, Phillip wrote:
> 
> If people really = think that Amazon.com is going to say 'I know that
> only 95% of = browsers support SHA1, but I am going to get an SHA2
> cert and = lose that 5% of sales so that our transactions are as
> secure as = possible' because someone finds a practical attack on
> SHA1, then = let them say that. So far nobody has challenged the
> analysis = directly, they have merely described themselves as
> unconvinced = that there is a problem.
> 

OK, so let's get real = here.  The reality is that transitioning between
crypto = algorithms is *hard*, and that the tragedy of the commons is
hitting = us hard.  We can try to create technical solutions (such as
the = Svengali-style suicide note which causes browsers to = break
intranets), but their have shortcomings because this is = fundamentally
a social problem.

There are couple of things we = need to do in order to successfully
carry off a migration:

(1) = We need to get browsers to add support for the new crypto = algorithm
(2) We need to get users to upgrade to the new browsers = with support
        for the new = crypto algorithm
(3) Once (1) and (2) are done, we need to get secure = commerce sites to
        upgrade = to use certificates that utilize the new crypto = algorithm.
        (In practice = this will be the crypto checksum; but the same = thing
        applies if we ever = need to get nervous about replacing the = PK
        algorithm.)

This = normally takes time --- years, but it is possible to speed = things
up.  For example, an interested body, perhaps funded by = far-sighted
merchants and other concerned citizens, could track which = browsers
have added the new algorithms, and jawbone (and perhaps in = the later
part of the effort, publically shame) entities distributing = browsers
to implement the new algorithm.

For (2), sites who = were interested in being "good citizens" could test
to see if the = browser supports the new crypto algorithm, and display a
"nag screen" = if the browser apparently doesn't support the new = crypto
algorithm.  Said nag message could be gentle at first, = but could get
increasingly strident; a lot of this would be up to the = web site(s)
involved, of course.

So it's possible to encourage = the ecosystem to move in a particular
way, but it all requires effort = and coordination, and the tragedy of
the commons is that until the = emergency comes up, it's unlikely that
such an effort will get = funding and support. 

But again, this is all nothing new, = and I suspect one of the reasons
why we're thrashing a little in this = discussion is because it really
is much more of a social problem than = a technical problem, which means
it's a bit outside of the IETF's = core competency.

        =         =         =         =         - = Ted

------_=_NextPart_001_01C99827.8E5140EA-- From sommerfeld@sun.com Thu Feb 26 07:58:34 2009 Return-Path: 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 05A213A68E8 for ; Thu, 26 Feb 2009 07:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 ptw0oBHXt2OD for ; Thu, 26 Feb 2009 07:58:33 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 39DF93A67F7 for ; Thu, 26 Feb 2009 07:58:33 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1QFwjtP019969; Thu, 26 Feb 2009 15:58:45 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1QFwiLa003813; Thu, 26 Feb 2009 10:58:44 -0500 (EST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1QFwhcx003575; Thu, 26 Feb 2009 07:58:43 -0800 (PST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1QFweR2003574; Thu, 26 Feb 2009 07:58:41 -0800 (PST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Theodore Tso In-Reply-To: <20090226143809.GF7227@mit.edu> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 26 Feb 2009 07:58:37 -0800 Message-Id: <1235663917.3293.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:58:34 -0000 On Thu, 2009-02-26 at 09:38 -0500, Theodore Tso wrote: > There are couple of things we need to do in order to successfully > carry off a migration: > > (1) ... > (2) ... > (3) Once (1) and (2) are done, So, that sort of transition plan is doomed. (1) and (2) will never be "done" because there will always be sites and clients running old software. What's more, software which has not been tested does not work. We don't know until we start trying to deploy sha-n certs on a wide scale if we got all the details right, and if we got something wrong and have to tweak the browsers again... IMHO we need a transition plan which allows websites to deploy with sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare mention it, we need to find some way to do this without making them pay a bunch of nuisance fees to CA operators). That way the hard part of the transition plan looks more like: n) release software which expects sha-n and considers sha-1 an exceptional case. and the triggering event for this can be somewhat more flexible. It may still happen shortly after a "cnn moment", but which would be a much more graceful transition than if we had to throw the switch starting today. From pbaker@verisign.com Thu Feb 26 08:04:34 2009 Return-Path: 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 C8E123A6B73 for ; Thu, 26 Feb 2009 08:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 kZa0s1x5bKd3 for ; Thu, 26 Feb 2009 08:04:33 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id BE5C73A6A65 for ; Thu, 26 Feb 2009 08:04:33 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QG4tih021873; Thu, 26 Feb 2009 08:04:55 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 08:04:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9982B.F68D809A" Date: Thu, 26 Feb 2009 08:04:54 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2D4@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmXmoPbHiUJDxxJSI6/JzhiZc+EuQAjSIzf References: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com><200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG><2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Paul Hoffman" , X-OriginalArrivalTime: 26 Feb 2009 16:04:54.0641 (UTC) FILETIME=[F6AE6610:01C9982B] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:04:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9982B.F68D809A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lets not debate the semantics of what is and is not a technical issue. =20 They are the issues that are critical to deployment of a successful = transition. Since we are (mostly) the people who care most about this = particular transition, it is up to us to understand the problem and find = a solution. =20 =20 So far the only real objection is to the implementation of the suicide = note. And what I am proposing is not really a suicide note in the manner = proposed by Rivest and Lampson. I am merely re-using his idea of a = self-authenticating statement that a key is no longer safe to use and = applying it to make a similarly secure statement about an algorithm. The = name seems to be distracting. =20 So lets call it a 'upgrade-available' note which is a closer description = in this case. =20 How about this as a mechanism: =20 * 'Upgrade-available' Note is established on a per CA-Root basis. * Each CA determines when they have full support deployed for OCSP = back-up authentication. * CA issues the 'Upgrade-available' note for their particular roots. * Henceforth browsers know that if they see a SHA1 cert they should = check for a SHAn OCSP token. * This mechanism is only enabled if the user has turned on OCSP = validation. =20 Binding the note to the particular root should avoid Jeff's issue. It = also removes the need for the CAs to move en-masse which is probably a = good thing but I will have to run some simulations to work out if that = is the case. =20 =20 This seems defensible to me. If I am the CA that stands behind a = certificate, I can tell people when it might be appropriate to perform = additional checks to make sure that a certificate is really valid. =20 If an enterprise is running its own CA it can make its own decision as = to when to tell capable browsers to use SHAn. =20 ________________________________ From: saag-bounces@ietf.org on behalf of Paul Hoffman Sent: Wed 2/25/2009 5:43 PM To: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition At 2:02 PM -0800 2/25/09, Hallam-Baker, Phillip wrote: >Let us stick to the technical issues here: > >* Is the current transition plan viable or does it fail in the way that = I predict >* Is the proposed solution viable? >* Is there a better solution? None of those are technical issues. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C9982B.F68D809A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
Lets not = debate the semantics of what is and is not a technical = issue.
=0A=
 
=0A=
They are the issues that are = critical to deployment of a successful transition. Since we are (mostly) = the people who care most about this particular transition, it is up to = us to understand the problem and find a solution.
=0A=
 
=0A=
 
=0A=
So far the only real = objection is to the implementation of the suicide note. And what I am = proposing is not really a suicide note in the manner proposed by Rivest = and Lampson. I am merely re-using his idea of a self-authenticating = statement that a key is no longer safe to use and applying it to make a = similarly secure statement about an algorithm. The name seems to be = distracting.
=0A=
 
=0A=
So lets call it a = 'upgrade-available' note which is a closer description in this = case.
=0A=
 
=0A=
How about this as a = mechanism:
=0A=
 
=0A=
* 'Upgrade-available' Note is established on a per = CA-Root basis.
=0A=
* Each CA determines when = they have full support deployed for OCSP back-up = authentication.
=0A=
* CA issues the = 'Upgrade-available' note for their particular roots.
=0A=
* Henceforth browsers know = that if they see a SHA1 cert they should check for a SHAn OCSP = token.
=0A=
* This mechanism is only = enabled if the user has turned on OCSP validation.
=0A=
 
=0A=
Binding the note to the = particular root should avoid Jeff's issue. It also removes the need for = the CAs to move en-masse which is probably a good thing but I will have = to run some simulations to work out if that is the case.
=0A=
 
=0A=
 
=0A=
This seems defensible to me. = If I am the CA that stands behind a certificate, I can tell people when = it might be appropriate to perform additional checks to make sure that a = certificate is really valid.
=0A=
 
=0A=
If an enterprise is running = its own CA it can make its own decision as to when to tell capable = browsers to use SHAn.
=0A=
 
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Paul Hoffman
Sent: Wed 2/25/2009 5:43 = PM
To: saag@ietf.org
Subject: Re: [saag] SHA-1 to = SHA-n transition

=0A=
=0A=

At 2:02 PM -0800 2/25/09, Hallam-Baker, Phillip = wrote:
>Let us stick to the technical issues = here:
>
>* Is the current transition plan viable or does it = fail in the way that I predict
>* Is the proposed solution = viable?
>* Is there a better solution?

None of those are = technical issues.

--Paul Hoffman, Director
--VPN = Consortium
_______________________________________________
saag = mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C9982B.F68D809A-- From pbaker@verisign.com Thu Feb 26 08:08:35 2009 Return-Path: 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 86B5928C1F4 for ; Thu, 26 Feb 2009 08:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.435 X-Spam-Level: X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 z3OKq1s3vDpL for ; Thu, 26 Feb 2009 08:08:30 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 0E3113A69F5 for ; Thu, 26 Feb 2009 08:08:29 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QG8oN5021999; Thu, 26 Feb 2009 08:08:50 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 08:08:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9982C.829E479A" Date: Thu, 26 Feb 2009 08:05:37 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2D6@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmYKy4+CGCwq+rESwGOOBJffP4v2QAAOHlO References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com><0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com><2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com><20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> From: "Hallam-Baker, Phillip" To: "Bill Sommerfeld" , "Theodore Tso" X-OriginalArrivalTime: 26 Feb 2009 16:08:50.0169 (UTC) FILETIME=[83111E90:01C9982C] Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:08:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9982C.829E479A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The need to test code paths is a really good point. =20 It might mean that we would want to avoid a hard-switchover. =20 But then it is hard to create a soft landing. ________________________________ From: Bill Sommerfeld [mailto:sommerfeld@sun.com] Sent: Thu 2/26/2009 10:58 AM To: Theodore Tso Cc: Hallam-Baker, Phillip; der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition On Thu, 2009-02-26 at 09:38 -0500, Theodore Tso wrote: > There are couple of things we need to do in order to successfully > carry off a migration: > > (1) ... > (2) ... > (3) Once (1) and (2) are done, So, that sort of transition plan is doomed. (1) and (2) will never be "done" because there will always be sites and clients running old software. What's more, software which has not been tested does not work. We don't know until we start trying to deploy sha-n certs on a wide scale if we got all the details right, and if we got something wrong and have to tweak the browsers again... IMHO we need a transition plan which allows websites to deploy with sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare mention it, we need to find some way to do this without making them pay a bunch of nuisance fees to CA operators). That way the hard part of the transition plan looks more like: n) release software which expects sha-n and considers sha-1 an exceptional case. and the triggering event for this can be somewhat more flexible. It may still happen shortly after a "cnn moment", but which would be a much more graceful transition than if we had to throw the switch starting today. ------_=_NextPart_001_01C9982C.829E479A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition=0A= =0A= =0A= =0A=
=0A=
The need to = test code paths is a really good point.
=0A=
 
=0A=
It might mean that we would = want to avoid a hard-switchover.
=0A=
 
=0A=
But then it is hard to create = a soft landing.
=0A=

=0A=
=0A= From: Bill Sommerfeld = [mailto:sommerfeld@sun.com]
Sent: Thu 2/26/2009 10:58 = AM
To: Theodore Tso
Cc: Hallam-Baker, Phillip; der = Mouse; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n = transition

=0A=

=0A=

On Thu, 2009-02-26 at 09:38 -0500, Theodore Tso = wrote:

> There are couple of things we need to do in order to = successfully
> carry off a migration:
>
> (1) = ...
> (2) ...
> (3) Once (1) and (2) are done, <deploy = certs using sha-n>

So, that sort of transition plan is = doomed.  (1) and (2) will never be
"done" because there will = always be sites and clients running old
software.

What's more, = software which has not been tested does not work.  We don't
know = until we start trying to deploy sha-n certs on a wide scale if we
got = all the details right, and if we got something wrong and have = to
tweak the browsers again...

IMHO we need a transition plan = which allows websites to deploy with
sha-n certs in parallel to sha-1 = certs from day 1 (and, if I dare
mention it, we need to find some way = to do this without making them pay
a bunch of nuisance fees to CA = operators).

That way the hard part of the transition plan looks = more like:

 n) release software which expects sha-n and = considers sha-1 an
exceptional case.

and the triggering event = for this can be somewhat more flexible.  It may
still happen = shortly after a "cnn moment", but which would be a much
more graceful = transition than if we had to throw the switch = starting
today.

------_=_NextPart_001_01C9982C.829E479A-- From Nicolas.Williams@sun.com Thu Feb 26 09:03:37 2009 Return-Path: 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 BB1303A6A65 for ; Thu, 26 Feb 2009 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Aqr2stZjJ8Dl for ; Thu, 26 Feb 2009 09:03:36 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C65323A68CB for ; Thu, 26 Feb 2009 09:03:36 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1QH3wYq008721 for ; Thu, 26 Feb 2009 17:03:58 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 n1QH3vOA064578 for ; Thu, 26 Feb 2009 10:03:57 -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 n1QGsqiA008930; Thu, 26 Feb 2009 10:54:52 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1QGsmLo008929; Thu, 26 Feb 2009 10:54:48 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 26 Feb 2009 10:54:48 -0600 From: Nicolas Williams To: Bill Sommerfeld Message-ID: <20090226165448.GK9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1235663917.3293.16.camel@localhost> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:03:37 -0000 On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld wrote: > IMHO we need a transition plan which allows websites to deploy with > sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare > mention it, we need to find some way to do this without making them pay > a bunch of nuisance fees to CA operators). Indeed. And not having to pay "nuisance fees to CA operators" falls out of not having a real PKI -- no real PKI, no real CAs to pay. What we need is something like DIGEST-MD5, but tied into browser apps in a different way than DIGEST-MD5 is today (more on this below). Given this we can forego PKI -- just do channel binding to TLS (with or without server certs, whether CA-issued or self-signed). My proposal: 1) Add JavaScript interfaces to deal with DIGEST-MD5, successors, GSS-API, ... These could be simple XmlHttpRequest object extensions, where DIGEST-MD5 can already be used, and where HTTP/Nego and successors could be used too. 2) Tie the above interfaces to the browser UI. Mark pages/windows/tabs with colors/text/sound/whatever appropriate markers as: - plain (nothing is authenticated) - weak server authentication (what we do today with HTTPS) - mutually authenticated (DIGEST-MD5/something else was used through the above mentioned interfaces, with credentials furnished through the trusted path) Add markers for degree of security based on crypto algs used. Make it simple for users to see the authenticated identities. We'll also need a new flavor of cookies. We have "secure" and "not secure" cookies now; we'll need "issued in mutually authenticated context" -- call them "authenticated cookies." Prompting for DIGEST-MD5/whatever credentials needs to be done securely. As with all UI design matters, it's important to find a way to prevent attackers from emulating the UI with enough fidelity. (E.g., don't allow full-screen apps.) 3) Teach users to look for the new markers. *This* is the hard part. Education will always be the hard part. (Not that UI design isn't hard -- it is, and it is a requirement to get the UI right if we're to educate users successfully.) 4) Federation/whatever fits into (2). We already have lots of federation choices. The propblem is how federation fits in generally. Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: it's completely piecemeal, there's no CAs to shame into getting SHA-n support because PKI gets cut out of the picture (even if server certs are still used, they no longer matter for security). TLS would still be used, so getting TLS implementations updated to 1.2 so that SHA-n would be a requirement. As would be a successor to DIGEST-MD5. We'd also be solving some of the other web security problems with this approach. Nico -- From hartmans@mit.edu Thu Feb 26 12:19:55 2009 Return-Path: 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 351C528C15F for ; Thu, 26 Feb 2009 12:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 tybqzK+kHtTw for ; Thu, 26 Feb 2009 12:19:54 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 81F3228C142 for ; Thu, 26 Feb 2009 12:19:54 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4BEDB4245; Thu, 26 Feb 2009 15:20:06 -0500 (EST) From: Sam Hartman To: Nicolas Williams References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> Date: Thu, 26 Feb 2009 15:20:06 -0500 In-Reply-To: <20090226165448.GK9992@Sun.COM> (Nicolas Williams's message of "Thu, 26 Feb 2009 10:54:48 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: der Mouse , saag@ietf.org Subject: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:19:55 -0000 Nico, while I'm in favor of channel binding and believe your approach has a lot of value, please be careful to apply it only where applicable. Phil is talking about the web browser PKI. Channel binding to existing authentication solves some problems in that space, but definitely not all. For example it is not useful for securing enrollment or certain classes of URI-only handoff. So, I think the web will continue to need a PKI.:-) From Nicolas.Williams@sun.com Thu Feb 26 12:45:22 2009 Return-Path: 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 EF1483A6818 for ; Thu, 26 Feb 2009 12:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.016, 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 mXmDdOeyfyZl for ; Thu, 26 Feb 2009 12:45:21 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 0A03128C166 for ; Thu, 26 Feb 2009 12:45:20 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1QKjgJZ013616 for ; Thu, 26 Feb 2009 20:45:42 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 n1QKjgcq058956 for ; Thu, 26 Feb 2009 13:45:42 -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 n1QKahfc009201; Thu, 26 Feb 2009 14:36:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1QKaXxf009200; Thu, 26 Feb 2009 14:36:33 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 26 Feb 2009 14:36:33 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20090226203633.GB9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:45:22 -0000 On Thu, Feb 26, 2009 at 03:20:06PM -0500, Sam Hartman wrote: > Nico, while I'm in favor of channel binding and believe your approach > has a lot of value, please be careful to apply it only where applicable. > > Phil is talking about the web browser PKI. Channel binding to > existing authentication solves some problems in that space, but > definitely not all. For example it is not useful for securing > enrollment or certain classes of URI-only handoff. > > So, I think the web will continue to need a PKI.:-) A PKI that does not exist. Channel binding is not a silver bullet, and in this case one could argue it ought not have a place. But given what we have to work with it seems like it can actually help. From pbaker@verisign.com Thu Feb 26 13:03:50 2009 Return-Path: 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 23E523A696B for ; Thu, 26 Feb 2009 13:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 NfOIXgVnx73b for ; Thu, 26 Feb 2009 13:03:49 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 0B1C928C30C for ; Thu, 26 Feb 2009 13:03:11 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QL3WT4002052; Thu, 26 Feb 2009 13:03:32 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 13:03:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99855.ADBD5BCE" Date: Thu, 26 Feb 2009 13:03:31 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2DA@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Channel binding is great but not a silver bullet Thread-Index: AcmYT6c/js0Io7T/TLW8ADuvnFl8OwABFFik References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com><0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com><2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com><20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost><20090226165448.GK9992@Sun.COM> From: "Hallam-Baker, Phillip" To: "Sam Hartman" , "Nicolas Williams" X-OriginalArrivalTime: 26 Feb 2009 21:03:31.0928 (UTC) FILETIME=[AE376D80:01C99855] Cc: der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:03:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99855.ADBD5BCE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Without wanting to go too far down this route.=20 =20 Yes the approach has merit and one can even imagine a situation in the = distant future where this type of approach transforms the role of CAs = rendering certain types of low assurance product obsolete. But what you = cannot get from that approach alone is a demonstration of accountability = which is the cornerstone of the Extended Validation design. =20 And even if we start right now, such a scheme requires deployment of a = whole new infrastructure and a whole new set of applications to run on = top of it. =20 While I certainly hope that it takes the cryptographers as long to turn = the SHA1 querry into a full break as it took them to convert the MD5 = compromise into a fuill break I do not want to depend on that. And I = certainly think that we, the crypto-security community are going to be = nervous about the security of SHA1 long before the rest of the industry = is. =20 =20 And even if such an infrastructure was deployed, the CAs wil still be in = business selling DV validated certs because there will still be a large = number of businesses that make support for legacy browsers a much higher = priority than not supporting crypto algorithms that make us nervous.=20 ________________________________ From: saag-bounces@ietf.org on behalf of Sam Hartman Sent: Thu 2/26/2009 3:20 PM To: Nicolas Williams Cc: der Mouse; saag@ietf.org Subject: [saag] Channel binding is great but not a silver bullet Nico, while I'm in favor of channel binding and believe your approach has a lot of value, please be careful to apply it only where applicable. Phil is talking about the web browser PKI. Channel binding to existing authentication solves some problems in that space, but definitely not all. For example it is not useful for securing enrollment or certain classes of URI-only handoff. So, I think the web will continue to need a PKI.:-) _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99855.ADBD5BCE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [saag] Channel binding is great but not a = silver bullet=0A= =0A= =0A= =0A=
=0A=
Without = wanting to go too far down this route.
=0A=
 
=0A=
Yes the = approach has merit and one can even imagine a situation in the distant = future where this type of approach transforms the role of CAs rendering = certain types of low assurance product obsolete. But what you cannot get = from that approach alone is a demonstration of accountability which is = the cornerstone of the Extended Validation design.
=0A=
 
=0A=
And even if we start right = now, such a scheme requires deployment of a whole new infrastructure and = a whole new set of applications to run on top of it.
=0A=
 
=0A=
While I certainly hope that = it takes the cryptographers as long to turn the SHA1 querry into a full = break as it took them to convert the MD5 compromise into a fuill break I = do not want to depend on that. And I certainly think that we, the = crypto-security community are going to be nervous about the security of = SHA1 long before the rest of the industry is.
=0A=
 
=0A=
 
=0A=
And even if such an = infrastructure was deployed, the CAs wil still be in business selling DV = validated certs because there will still be a large number of businesses = that make support for legacy browsers a much higher priority than not = supporting crypto algorithms that make us nervous.
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Sam Hartman
Sent: Thu 2/26/2009 3:20 = PM
To: Nicolas Williams
Cc: der Mouse; = saag@ietf.org
Subject: [saag] Channel binding is great but not = a silver bullet

=0A=
=0A=

Nico, while I'm in favor of channel binding and = believe your approach
has a lot of value, please be careful to apply = it only where applicable.

Phil is talking about the web browser = PKI.  Channel binding to
existing authentication solves some = problems in that space, but
definitely not all.  For example it = is not useful for securing
enrollment or certain classes of URI-only = handoff.

So, I think the web will continue to need a = PKI.:-)

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

------_=_NextPart_001_01C99855.ADBD5BCE-- From ekr@networkresonance.com Thu Feb 26 18:00:49 2009 Return-Path: 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 19D863A68CD for ; Thu, 26 Feb 2009 18:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] 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 nJx47NAlei8R for ; Thu, 26 Feb 2009 18:00:48 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 130163A67B4 for ; Thu, 26 Feb 2009 18:00:48 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8D45150822; Thu, 26 Feb 2009 18:23:59 -0800 (PST) Date: Thu, 26 Feb 2009 18:23:59 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20090226165448.GK9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090227022359.8D45150822@romeo.rtfm.com> Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 02:00:49 -0000 At Thu, 26 Feb 2009 10:54:48 -0600, Nicolas Williams wrote: > > On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld wrote: > > IMHO we need a transition plan which allows websites to deploy with > > sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare > > mention it, we need to find some way to do this without making them pay > > a bunch of nuisance fees to CA operators). > > Indeed. And not having to pay "nuisance fees to CA operators" falls out > of not having a real PKI -- no real PKI, no real CAs to pay. > > What we need is something like DIGEST-MD5, but tied into browser apps in > a different way than DIGEST-MD5 is today (more on this below). Given > this we can forego PKI -- just do channel binding to TLS (with or > without server certs, whether CA-issued or self-signed). > > My proposal: > > 1) Add JavaScript interfaces to deal with DIGEST-MD5, successors, > GSS-API, ... > > These could be simple XmlHttpRequest object extensions, where > DIGEST-MD5 can already be used, and where HTTP/Nego and successors > could be used too. > > 2) Tie the above interfaces to the browser UI. > > Mark pages/windows/tabs with colors/text/sound/whatever appropriate > markers as: > > - plain (nothing is authenticated) > - weak server authentication (what we do today with HTTPS) > - mutually authenticated (DIGEST-MD5/something else was used through > the above mentioned interfaces, with credentials furnished through > the trusted path) > > Add markers for degree of security based on crypto algs used. > > Make it simple for users to see the authenticated identities. > > We'll also need a new flavor of cookies. We have "secure" and "not > secure" cookies now; we'll need "issued in mutually authenticated > context" -- call them "authenticated cookies." > > Prompting for DIGEST-MD5/whatever credentials needs to be done > securely. > > As with all UI design matters, it's important to find a way to > prevent attackers from emulating the UI with enough fidelity. (E.g., > don't allow full-screen apps.) > > 3) Teach users to look for the new markers. *This* is the hard part. > Education will always be the hard part. > > (Not that UI design isn't hard -- it is, and it is a requirement to > get the UI right if we're to educate users successfully.) I don't want to get into an extensive argument about this on SAAG, but I don't think this direction is particularly promising, for reasons I've indicated before: namely that you're handwaving the difficult part of the problem, UI, which we have no real idea how to solve. Sure, if we solved that, there are any number of things we could do, but absent that, the other things are fairly useless. > 4) Federation/whatever fits into (2). We already have lots of > federation choices. The propblem is how federation fits in > generally. > > Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: it's > completely piecemeal, there's no CAs to shame into getting SHA-n support > because PKI gets cut out of the picture (even if server certs are still > used, they no longer matter for security). TLS would still be used, so > getting TLS implementations updated to 1.2 so that SHA-n would be a > requirement. As would be a successor to DIGEST-MD5. I think you're rather overselling here: this only works well for account-based systems. There are plenty of cases where I need to connect to someone where I only know their name but I don't yet have an account (e.g., https://www.amazon.com). The mechanism that you provide doesn't work at all in this case. Rather, you need some third-party verifiable mechanism. I suppose one could argue that certs aren't a good such mechanism, but they're the one that TLS supports and I suspect any replacement would smell a lot like certs. -Ekr From Nicolas.Williams@sun.com Thu Feb 26 20:04:33 2009 Return-Path: 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 E976E28C25F for ; Thu, 26 Feb 2009 20:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.023, 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 fkO5NP4s1qpq for ; Thu, 26 Feb 2009 20:04:33 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 428C93A67FF for ; Thu, 26 Feb 2009 20:04:33 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1R44tae004722 for ; Fri, 27 Feb 2009 04:04:55 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 n1R44tHW012575 for ; Thu, 26 Feb 2009 21:04:55 -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 n1R3tuBc010050; Thu, 26 Feb 2009 21:55:56 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1R3ts2K010049; Thu, 26 Feb 2009 21:55:54 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 26 Feb 2009 21:55:54 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20090227035553.GT9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090227022359.8D45150822@romeo.rtfm.com> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 04:04:34 -0000 On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote: > I think you're rather overselling here: this only works well for > account-based systems. There are plenty of cases where I need to > connect to someone where I only know their name but I don't yet have > an account (e.g., https://www.amazon.com). The mechanism that you > provide doesn't work at all in this case. Rather, you need some > third-party verifiable mechanism. I suppose one could argue that certs > aren't a good such mechanism, but they're the one that TLS supports > and I suspect any replacement would smell a lot like certs. This is quite true. I did not address enrolment, nor cases where there is simply no relationship to be had. A PKI would sure be nice; I just don't believe we'll have something very close to one. Regardless of what we do we're likely to just muddle through in the end. From pgut001@cs.auckland.ac.nz Thu Feb 26 22:55:58 2009 Return-Path: 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 8F0653A67F3 for ; Thu, 26 Feb 2009 22:55:58 -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 UW4RGOw06XWw for ; Thu, 26 Feb 2009 22:55:57 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id CE9E33A67A5 for ; Thu, 26 Feb 2009 22:55:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 19D6A4820C4; Fri, 27 Feb 2009 19:56:17 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBml8J5sFjCi; Fri, 27 Feb 2009 19:56:16 +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 8199E481B21; Fri, 27 Feb 2009 19:56:16 +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 92D891DE4001; Fri, 27 Feb 2009 19:56:12 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lcwdo-0006dv-ES; Fri, 27 Feb 2009 19:56:12 +1300 From: Peter Gutmann To: Nicolas.Williams@sun.com, sommerfeld@sun.com In-Reply-To: <20090226165448.GK9992@Sun.COM> Message-Id: Sender: pgut001 Date: Fri, 27 Feb 2009 19:56:12 +1300 Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:55:58 -0000 Nicolas Williams writes: >What we need is something like DIGEST-MD5, but tied into browser apps in a >different way than DIGEST-MD5 is today (more on this below). Given this we >can forego PKI -- just do channel binding to TLS (with or without server >certs, whether CA-issued or self-signed). We already have this, and have had for some years, it's called TLS-PSK. Unfortunately the browser vendors' approach is to keep on waiting for PKI to start working, forever if necessary. "PKI meurt, elle ne se rend pas!" [0]. Peter. [0] Hat tip to Luther Martin for the quote :-). From pbaker@verisign.com Fri Feb 27 05:35:04 2009 Return-Path: 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 C8F623A6888 for ; Fri, 27 Feb 2009 05:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SvQM6h51923f for ; Fri, 27 Feb 2009 05:35:03 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E69183A67A4 for ; Fri, 27 Feb 2009 05:35:03 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n1RDAxuX025662; Fri, 27 Feb 2009 05:10:59 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 05:35:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C998E0.3DB591BA" Date: Fri, 27 Feb 2009 05:35:23 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2DD@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmYkI/V0sVKQzO8QkanRpDA7kgsqQATrDAG References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com><0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com><2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com><20090226143809.GF7227@mit.edu><1235663917.3293.16.camel@localhost><20090226165448.GK9992@Sun.COM><20090227022359.8D45150822@romeo.rtfm.com> <20090227035553.GT9992@Sun.COM> From: "Hallam-Baker, Phillip" To: "Nicolas Williams" , "Eric Rescorla" X-OriginalArrivalTime: 27 Feb 2009 13:35:24.0801 (UTC) FILETIME=[3EA72F10:01C998E0] Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:35:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998E0.3DB591BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have a PKI. We have had a PKI for fifteen years. Its just a PKI that = requires people to pay for service.=20 If the only PKI that counts is a completely free at point of delivery = PKI then I guess that we don't have a DNS system either since the NSF = decided to start charging. What you mean is that a completely free to use PKI would be nice. We actually have one of those, SSH works quite nicely for what it does. = Just not for assuring potential customers that a credit card transaction = is safe for them. Problem is that there are some tasks that really don't work as community = efforts. Auditing and preparing taxes for example. If folk work out how = to make those work on an open source type model we could maybe try a CA. What we need to do here is to fix the PKI that we have already deployed = and is serving a million Web merchants. Or rather, take out an insurance = policy in case we need to fix it at short notice. -----Original Message----- From: saag-bounces@ietf.org on behalf of Nicolas Williams Sent: Thu 2/26/2009 10:55 PM To: Eric Rescorla Cc: der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =20 On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote: > I think you're rather overselling here: this only works well for > account-based systems. There are plenty of cases where I need to > connect to someone where I only know their name but I don't yet have > an account (e.g., https://www.amazon.com). The mechanism that you > provide doesn't work at all in this case. Rather, you need some > third-party verifiable mechanism. I suppose one could argue that certs > aren't a good such mechanism, but they're the one that TLS supports > and I suspect any replacement would smell a lot like certs. This is quite true. I did not address enrolment, nor cases where there is simply no relationship to be had. A PKI would sure be nice; I just don't believe we'll have something very close to one. Regardless of what we do we're likely to just muddle through in the end. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C998E0.3DB591BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] SHA-1 to SHA-n transition

We have a PKI. We have had a PKI for fifteen years. = Its just a PKI that requires people to pay for service.

If the only PKI that counts is a completely free at point of delivery = PKI then I guess that we don't have a DNS system either since the NSF = decided to start charging.


What you mean is that a completely free to use PKI would be nice.

We actually have one of those, SSH works quite nicely for what it does. = Just not for assuring potential customers that a credit card transaction = is safe for them.

Problem is that there are some tasks that really don't work as community = efforts. Auditing and preparing taxes for example. If folk work out how = to make those work on an open source type model we could maybe try a = CA.


What we need to do here is to fix the PKI that we have already deployed = and is serving a million Web merchants. Or rather, take out an insurance = policy in case we need to fix it at short notice.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Nicolas Williams
Sent: Thu 2/26/2009 10:55 PM
To: Eric Rescorla
Cc: der Mouse; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote:
> I think you're rather overselling here: this only works well = for
> account-based systems. There are plenty of cases where I need = to
> connect to someone where I only know their name but I don't yet = have
> an account (e.g., https://www.amazon.com). The = mechanism that you
> provide doesn't work at all in this case. Rather, you need some
> third-party verifiable mechanism. I suppose one could argue that = certs
> aren't a good such mechanism, but they're the one that TLS = supports
> and I suspect any replacement would smell a lot like certs.

This is quite true.  I did not address enrolment, nor cases where = there
is simply no relationship to be had.  A PKI would sure be nice; I = just
don't believe we'll have something very close to one.

Regardless of what we do we're likely to just muddle through in the = end.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C998E0.3DB591BA-- From pbaker@verisign.com Fri Feb 27 05:40:42 2009 Return-Path: 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 055D93A67A4 for ; Fri, 27 Feb 2009 05:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ab5QpbdZFaGa for ; Fri, 27 Feb 2009 05:40:40 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id B20443A67D7 for ; Fri, 27 Feb 2009 05:40:40 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1RDf2NS027923; Fri, 27 Feb 2009 05:41:02 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 05:41:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C998E1.07127472" Date: Fri, 27 Feb 2009 05:41:01 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2DE@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmYf0ZGufii+X0sR7maagS/QTBWEQAYQmXr References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com><0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com><2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com><20090226143809.GF7227@mit.edu><1235663917.3293.16.camel@localhost><20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> From: "Hallam-Baker, Phillip" To: "Eric Rescorla" , "Nicolas Williams" X-OriginalArrivalTime: 27 Feb 2009 13:41:03.0264 (UTC) FILETIME=[08648A00:01C998E1] Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:40:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998E1.07127472 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable EKR,=20 I would like to dispute one small part of this. I think we do know = something about UI. A UI works if the user has to do absolutely nothing to be secure. The = more that a user is required to do, the less likely they are to do it = correctly. Since we cannot expect the end user to know SHA1 or SHA2 from a potato = we cannot present the typical user with any UI change whatsoever. End of = story. We can put some options in for the expert user, but we probably don't = want those to be too easy to get at. -----Original Message----- From: saag-bounces@ietf.org on behalf of Eric Rescorla Sent: Thu 2/26/2009 9:23 PM To: Nicolas Williams Cc: der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =20 At Thu, 26 Feb 2009 10:54:48 -0600, Nicolas Williams wrote: >=20 > On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld wrote: > > IMHO we need a transition plan which allows websites to deploy with > > sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare > > mention it, we need to find some way to do this without making them = pay > > a bunch of nuisance fees to CA operators). >=20 > Indeed. And not having to pay "nuisance fees to CA operators" falls = out > of not having a real PKI -- no real PKI, no real CAs to pay. >=20 > What we need is something like DIGEST-MD5, but tied into browser apps = in > a different way than DIGEST-MD5 is today (more on this below). Given > this we can forego PKI -- just do channel binding to TLS (with or > without server certs, whether CA-issued or self-signed). > > My proposal: >=20 > 1) Add JavaScript interfaces to deal with DIGEST-MD5, successors, > GSS-API, ... >=20 > These could be simple XmlHttpRequest object extensions, where > DIGEST-MD5 can already be used, and where HTTP/Nego and successors > could be used too. > > 2) Tie the above interfaces to the browser UI. >=20 > Mark pages/windows/tabs with colors/text/sound/whatever appropriate > markers as: >=20 > - plain (nothing is authenticated) > - weak server authentication (what we do today with HTTPS) > - mutually authenticated (DIGEST-MD5/something else was used = through > the above mentioned interfaces, with credentials furnished = through > the trusted path) >=20 > Add markers for degree of security based on crypto algs used. >=20 > Make it simple for users to see the authenticated identities. >=20 > We'll also need a new flavor of cookies. We have "secure" and "not > secure" cookies now; we'll need "issued in mutually authenticated > context" -- call them "authenticated cookies." >=20 > Prompting for DIGEST-MD5/whatever credentials needs to be done > securely. >=20 > As with all UI design matters, it's important to find a way to > prevent attackers from emulating the UI with enough fidelity. = (E.g., > don't allow full-screen apps.) > > 3) Teach users to look for the new markers. *This* is the hard part. > Education will always be the hard part. >=20 > (Not that UI design isn't hard -- it is, and it is a requirement to > get the UI right if we're to educate users successfully.) I don't want to get into an extensive argument about this on SAAG, but I don't think this direction is particularly promising, for reasons I've indicated before: namely that you're handwaving the difficult part of the problem, UI, which we have no real=20 idea how to solve. Sure, if we solved that, there are any number of things we could do, but absent that, the other things are fairly useless. > 4) Federation/whatever fits into (2). We already have lots of > federation choices. The propblem is how federation fits in > generally. >=20 > Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: = it's > completely piecemeal, there's no CAs to shame into getting SHA-n = support > because PKI gets cut out of the picture (even if server certs are = still > used, they no longer matter for security). TLS would still be used, = so > getting TLS implementations updated to 1.2 so that SHA-n would be a > requirement. As would be a successor to DIGEST-MD5. I think you're rather overselling here: this only works well for account-based systems. There are plenty of cases where I need to connect to someone where I only know their name but I don't yet have an account (e.g., https://www.amazon.com). The mechanism that you provide doesn't work at all in this case. Rather, you need some third-party verifiable mechanism. I suppose one could argue that certs aren't a good such mechanism, but they're the one that TLS supports and I suspect any replacement would smell a lot like certs. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C998E1.07127472 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] SHA-1 to SHA-n transition

EKR,

I would like to dispute one small part of this. I think we do know = something about UI.

A UI works if the user has to do absolutely nothing to be secure. The = more that a user is required to do, the less likely they are to do it = correctly.

Since we cannot expect the end user to know SHA1 or SHA2 from a potato = we cannot present the typical user with any UI change whatsoever. End of = story.

We can put some options in for the expert user, but we probably don't = want those to be too easy to get at.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Eric Rescorla
Sent: Thu 2/26/2009 9:23 PM
To: Nicolas Williams
Cc: der Mouse; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

At Thu, 26 Feb 2009 10:54:48 -0600,
Nicolas Williams wrote:
>
> On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld = wrote:
> > IMHO we need a transition plan which allows websites to deploy = with
> > sha-n certs in parallel to sha-1 certs from day 1 (and, if I = dare
> > mention it, we need to find some way to do this without making = them pay
> > a bunch of nuisance fees to CA operators).
>
> Indeed.  And not having to pay "nuisance fees to CA = operators" falls out
> of not having a real PKI -- no real PKI, no real CAs to pay.
>
> What we need is something like DIGEST-MD5, but tied into browser = apps in
> a different way than DIGEST-MD5 is today (more on this = below).  Given
> this we can forego PKI -- just do channel binding to TLS (with = or
> without server certs, whether CA-issued or self-signed).
>
> My proposal:
>
> 1) Add JavaScript interfaces to deal with DIGEST-MD5, = successors,
>    GSS-API, ...
>
>    These could be simple XmlHttpRequest object = extensions, where
>    DIGEST-MD5 can already be used, and where = HTTP/Nego and successors
>    could be used too.
>
> 2) Tie the above interfaces to the browser UI.
>
>    Mark pages/windows/tabs with = colors/text/sound/whatever appropriate
>    markers as:
>
>     - plain (nothing is authenticated)
>     - weak server authentication (what we do = today with HTTPS)
>     - mutually authenticated = (DIGEST-MD5/something else was used through
>       the above mentioned interfaces, = with credentials furnished through
>       the trusted path)
>
>    Add markers for degree of security based on = crypto algs used.
>
>    Make it simple for users to see the authenticated = identities.
>
>    We'll also need a new flavor of cookies.  We = have "secure" and "not
>    secure" cookies now; we'll need "issued = in mutually authenticated
>    context" -- call them "authenticated = cookies."
>
>    Prompting for DIGEST-MD5/whatever credentials = needs to be done
>    securely.
>
>    As with all UI design matters, it's important to = find a way to
>    prevent attackers from emulating the UI with = enough fidelity.  (E.g.,
>    don't allow full-screen apps.)
>
> 3) Teach users to look for the new markers.  *This* is the = hard part.
>    Education will always be the hard part.
>
>    (Not that UI design isn't hard -- it is, and it = is a requirement to
>    get the UI right if we're to educate users = successfully.)


I don't want to get into an extensive argument about this on SAAG,
but I don't think this direction is particularly promising, for
reasons I've indicated before: namely that you're handwaving
the difficult part of the problem, UI, which we have no real
idea how to solve. Sure, if we solved that, there are any
number of things we could do, but absent that, the other things
are fairly useless.


> 4) Federation/whatever fits into (2).  We already have lots = of
>    federation choices.  The propblem is how = federation fits in
>    generally.
>
> Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: = it's
> completely piecemeal, there's no CAs to shame into getting SHA-n = support
> because PKI gets cut out of the picture (even if server certs are = still
> used, they no longer matter for security).  TLS would still be = used, so
> getting TLS implementations updated to 1.2 so that SHA-n would be = a
> requirement.  As would be a successor to DIGEST-MD5.

I think you're rather overselling here: this only works well for
account-based systems. There are plenty of cases where I need to
connect to someone where I only know their name but I don't yet have
an account (e.g., https://www.amazon.com). The = mechanism that you
provide doesn't work at all in this case. Rather, you need some
third-party verifiable mechanism. I suppose one could argue that = certs
aren't a good such mechanism, but they're the one that TLS supports
and I suspect any replacement would smell a lot like certs.

-Ekr



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

------_=_NextPart_001_01C998E1.07127472--