IETF Logo Mail Archive

Re: [dnsext] Clarifying the mandatory algorithm rules

Ondřej Surý <ondrej.sury@nic.cz> Thu, 18 November 2010 20:20 UTC

Return-Path: <ondrej.sury@nic.cz>
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 884EF28C10B for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 12:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.253
X-Spam-Level:
X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 ci2TrWjjjFO8 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 12:20:08 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 3391228C103 for <dnsext@ietf.org>; Thu, 18 Nov 2010 12:20:08 -0800 (PST)
Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 786B573440B for <dnsext@ietf.org>; Thu, 18 Nov 2010 21:20:55 +0100 (CET)
Message-ID: <4CE58AA6.80105@nic.cz>
Date: Thu, 18 Nov 2010 21:20:54 +0100
From: Ondřej Surý <ondrej.sury@nic.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: dnsext@ietf.org
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> <82y68qd8w9.fsf@mid.bfk.de>
In-Reply-To: <82y68qd8w9.fsf@mid.bfk.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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 20:20:09 -0000

On 18.11.2010 15:05, Florian Weimer wrote:
> * 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.

(See my other mail.)  You don't get a downgrade protection before 
chaining the new algorithm to the parent zone.

> 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.

Dropping the know-to-be-broken algorithms doesn't help the old 
non-upgraded resolvers, hence we should not rely on anything like that.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:ondrej.sury@nic.cz    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

v2.23.0 | Report a Bug | By Email