Re: [dnsext] Clarifying the mandatory algorithm rules

"George Barwood" <george.barwood@blueyonder.co.uk> Fri, 19 November 2010 07:05 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 5CEDE3A6897 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:05:44 -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.465, BAYES_20=-0.74, HELO_EQ_BLUEYON=1.4, MIME_BASE64_TEXT=1.753]
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 2LucWlG9jI6y for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:05:43 -0800 (PST)
Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 603CC3A67D6 for <dnsext@ietf.org>; Thu, 18 Nov 2010 23:05:43 -0800 (PST)
Received: from [172.23.144.249] (helo=asmtp-out5.blueyonder.co.uk) by smtp-out5.blueyonder.co.uk with esmtp (Exim 4.52) id 1PJL3H-0007ga-62; Fri, 19 Nov 2010 07:06:31 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1PJL2n-0003GF-UI; Fri, 19 Nov 2010 07:06:01 +0000
Message-ID: <AFBF51CC167047FFBACF69436F11A6F2@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: dnsext@ietf.org, Mark Andrews <marka@isc.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org><4CE53927.9090203@isc.org> <4CE58E90.6030607@nic.cz><AANLkTin2H7UkP7FVfz3GN74CKtqn2OKo7MmcKMGOkvNY@mail.gmail.com><4CE59B3D.5020109@nic.cz> <20101119004134.993F26EB749@drugs.dv.isc.org>
Date: Fri, 19 Nov 2010 07:06:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
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: Fri, 19 Nov 2010 07:05:44 -0000

----- Original Message ----- 
From: "Mark Andrews" <marka@isc.org>
To: <dnsext@ietf.org>
Sent: Friday, November 19, 2010 12:41 AM
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules


> I think the paragraph in question should be relaxed to make to MUST
> only apply to algorithms listed in the DS / published trust anchors.
> This will allow for gradual introduction of RRSIG for new algorithms.
> The current wording prevents this and is a real pain for large
> zones.

+1

This is how a reasonable person would expect it to work without
consulting the standard, and is the most logical approach.

It reproduces what happens when a zone is first signed, that is
until the DS / trust anchor is published, no verification occurs.

It simplifies removal of an algorithm, by removing the need
to (temporarily) continue to sign RRsets with keys that have
just been removed from the DNSKEY RRset.

The problem I guess is that this is a change to the standard,
and the benefits are not entirely decisive. However if it is
not done I expect zone operators to repeatedly make the same
mistake when changing algorithms.

- George