Re: [therightkey] algorithm blacklisting

Ralph Holz <holz@net.in.tum.de> Fri, 03 January 2014 17:37 UTC

Return-Path: <holz@net.in.tum.de>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DCD1AE02F for <therightkey@ietfa.amsl.com>; Fri, 3 Jan 2014 09:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.55
X-Spam-Level:
X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFanXErJApJX for <therightkey@ietfa.amsl.com>; Fri, 3 Jan 2014 09:37:51 -0800 (PST)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9D1AE035 for <therightkey@ietf.org>; Fri, 3 Jan 2014 09:37:51 -0800 (PST)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id B0D6180B14; Fri, 3 Jan 2014 18:37:43 +0100 (CET)
Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id B760C80B11 for <therightkey@ietf.org>; Fri, 3 Jan 2014 18:37:42 +0100 (CET)
Message-ID: <52C6F566.8010409@net.in.tum.de>
Date: Fri, 03 Jan 2014 18:37:42 +0100
From: Ralph Holz <holz@net.in.tum.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: therightkey@ietf.org
References: <CEEC5C32.C9C9%carl@redhoundsoftware.com>
In-Reply-To: <CEEC5C32.C9C9%carl@redhoundsoftware.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [therightkey] algorithm blacklisting
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2014 17:37:53 -0000

Hi,

>> Alternatively, pull the root cert from which MD5 signatures were issued.
>> As the MD5 attack still had considerable cost (for the hobby blackhat,
>> not a 3-letter agency), it was deemed that this must suffice for a while.
> 
> To make the discussion CT-compliant, having logs provide a list of
> algorithms that are used by each CA would be a nice feature to enable
> decisions like this.

Although, in the case you mention, that would not help all that much.
Fortunately, the days of MD5 in X.509 are over.

But in fact, I've been thinking for a while that an additional
monitoring infrastructure would be a nice-to-have thing in addition to
CT --- and, FWIW, also TACK --- I view both drafts as naturally
complementing each other.

CT, for example, is not meant to address the issue of whether
certificates have been deployed correctly (e.g. correct host). I think
active scans are still worthwhile to collect such information.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF