Re: [dnsext] Clarifying the mandatory algorithm rules

Florian Weimer <fweimer@bfk.de> Thu, 18 November 2010 14:04 UTC

Return-Path: <fweimer@bfk.de>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C8D3A680B for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 06:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.962
X-Spam-Level:
X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 JoQbAc39bAhE for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 06:04:57 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id CAE283A6809 for <dnsext@ietf.org>; Thu, 18 Nov 2010 06:04:55 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PJ57O-0006tX-4I; Thu, 18 Nov 2010 14:05:42 +0000
Received: by bfk.de with local id 1PJ57O-0008KZ-1U; Thu, 18 Nov 2010 14:05:42 +0000
To: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE50C01.4010104@nic.cz> <alpine.BSF.2.00.1011180630550.83352@fledge.watson.org> <4CE515ED.5010009@nlnetlabs.nl>
From: Florian Weimer <fweimer@bfk.de>
Date: Thu, 18 Nov 2010 14:05:42 +0000
In-Reply-To: <4CE515ED.5010009@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Thu\, 18 Nov 2010 13\:02\:53 +0100")
Message-ID: <82y68qd8w9.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2010 14:04:57 -0000

* W. C. A. Wijngaards:

> That is what unbound does.  And it gets algorithm downgrade protection
> security as a benefit (for the algorithms that it implements).

And I don't see any other way to get a priori downgrade protection.
There is no ordering of algorithm strengths.  For example, we don't
know if SHA-1 or SHA-256 will be broken first.

A posterio, you can drop validation for known-to-be-broken algorithms.
But even that might be not so easy because it's somewhat subjective
when an algorithm is broken.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99