Re: [dnsext] Clarifying the mandatory algorithm rules

Ondřej Surý <ondrej.sury@nic.cz> Fri, 19 November 2010 07:01 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 6E4133A67E6 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level:
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.325, 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 G8otgl3tLJ4d for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:01:24 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id D0EA13A67D6 for <dnsext@ietf.org>; Thu, 18 Nov 2010 23:01:23 -0800 (PST)
Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 2CDDC73437B for <dnsext@ietf.org>; Fri, 19 Nov 2010 08:02:10 +0100 (CET)
Message-ID: <4CE620F1.1060103@nic.cz>
Date: Fri, 19 Nov 2010 08:02:09 +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> <4CE53927.9090203@isc.org> <4CE58E90.6030607@nic.cz> <AANLkTin2H7UkP7FVfz3GN74CKtqn2OKo7MmcKMGOkvNY@mail.gmail.com><4CE59B3D.5020109@nic.cz> <20101119004134.993F26EB749@drugs.dv.isc.org>
In-Reply-To: <20101119004134.993F26EB749@drugs.dv.isc.org>
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: Fri, 19 Nov 2010 07:01:25 -0000

On 19.11.2010 01:41, Mark Andrews wrote:
> If you want to do downgrade protection between algorithms one can
> but only for the algorithms listed in the DS / trust-anchors.  They
> are the only algorithms that the zone operator has made any claims
> of existance for.
>
> 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.

I agree.  That was exactly what I was trying to say in my last few emails.

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