Re: [dnsext] Clarifying the mandatory algorithm rules

Ondřej Surý <ondrej.sury@nic.cz> Thu, 18 November 2010 21:30 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 E54DB3A68EF for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 13:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.342
X-Spam-Level:
X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.357, 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 bbEHD8NcXB46 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 13:30:57 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id CCC2A3A68CF for <dnsext@ietf.org>; Thu, 18 Nov 2010 13:30:56 -0800 (PST)
Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 660597342F3 for <dnsext@ietf.org>; Thu, 18 Nov 2010 22:31:42 +0100 (CET)
Message-ID: <4CE59B3D.5020109@nic.cz>
Date: Thu, 18 Nov 2010 22:31:41 +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>
In-Reply-To: <AANLkTin2H7UkP7FVfz3GN74CKtqn2OKo7MmcKMGOkvNY@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-2"; 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 21:30:58 -0000

On 18.11.2010 22:02, Brian Dickson wrote:
> I think there is wiggle room for the addition of new DNSKEYs and
> algorithms, via the ZSK/KSK linkage, that differs slightly.

Indeed.  But I see that as a variation of "must have a chain of trust" 
and relation between DS(parent)-DNSKEY(child).

> I.e. KSK must match DS for algorithms, and ZSK must match RRSIG for
> algorithms. It is possible that algorithms present in ZSKs are not
> present in KSKs.

Although bind doesn't treat this case as a valid zone and 
dnssec-signzone has to be silenced with -P, I was unable to find the 
reference to invalidity of such zone neither in 403[3-5] nor 3757.  That 
doesn't mean it doesn't exists, just that I didn't find it.

> And in such a case, unbound is correct and bind is incorrect, IMHO.

My feeling is that the same rule about DS-DNSKEY should apply for 
KSK-ZSK.  So if you publish a ZSK(A) and ZSK(B) and sign them with your 
KSK, you have to have RRSIG(ZSK(A)) and RRSIG(ZSK(B)) over all RRs in 
your zone.

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