Re: [dnsext] Clarifying the mandatory algorithm rules

Samuel Weiler <weiler@watson.org> Thu, 18 November 2010 15:16 UTC

Return-Path: <weiler@watson.org>
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 5312B3A6836 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 07:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 0SfJB2t+d6mM for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 07:16:34 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 79D683A67AF for <dnsext@ietf.org>; Thu, 18 Nov 2010 07:16:34 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oAIFHLax012623; Thu, 18 Nov 2010 10:17:22 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oAIFHLWE012620; Thu, 18 Nov 2010 10:17:21 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 18 Nov 2010 10:17:21 -0500
From: Samuel Weiler <weiler@watson.org>
To: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
In-Reply-To: <4CE515ED.5010009@nlnetlabs.nl>
Message-ID: <alpine.BSF.2.00.1011181007230.2821@fledge.watson.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>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 18 Nov 2010 10:17:22 -0500 (EST)
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 15:16:35 -0000

On Thu, 18 Nov 2010, W.C.A. Wijngaards wrote:

> Since owners MUST sign their zone correctly, I see no need to 
> specify a MUST accept missing signatures if you implement the other 
> algorithm? Why do you want to allow inproperly-signed zones?  It 
> will break resolvers that implement only a subset of algorithms?

Honestly, I haven't thought about the constraint in this light.

Some hisorical perspective may help.

Before these mandatory algorithm rules were adopted, a "properly 
signed" zone required that each RRset be signed by ANY of the DNSKEYs 
in the zone, with no regard to algorithms.  Some RRsets could be 
signed only with alg 5, some only with alg 234, and some with both.

We adopted these mandatory algorithm rules to deal with a particular 
downgrade attack (or, depending on how you look at it, a debilitating 
incentive against deploying a new algorithm).  For this purpose, it 
was (and is) sufficient to require a zone to follow the rules.  It was 
(and is) not necessary to require the resolver to check that the zone 
had followed the rules.


So we're starting from different places: I still remember the 
arguments from 2003 about why we should have ANY restrictions.  I also 
remember talking about whether we wanted to address other downgrade 
possibilities (e.g. key length) -- the WG decided not to tackle any of 
that.

-- Sam