[dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs

Samuel Weiler <weiler@watson.org> Fri, 01 April 2011 14:26 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 2A85E3A6864 for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.658
X-Spam-Level:
X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 D5u9W5sfj1KR for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:26:35 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6D9173A6845 for <dnsext@ietf.org>; Fri, 1 Apr 2011 07:26:35 -0700 (PDT)
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 p31ESFdh094727 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:28:15 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p31ESFKL094724 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:28:15 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 01 Apr 2011 10:28:15 -0400
From: Samuel Weiler <weiler@watson.org>
To: dnsext@ietf.org
In-Reply-To: <alpine.BSF.2.00.1104011022030.92106@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.1104011024530.92106@fledge.watson.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <alpine.BSF.2.00.1103141750530.74870@fledge.watson.org> <a06240800c9a50cf4632a@10.31.200.110> <AANLkTimUUa5zkr+hZH4jR-euENg_n=9EwtRVBN-cxr9_@mail.gmail.com> <a06240802c9a7b6cb4cc3@192.168.1.105> <AANLkTin+hMZ-27VjkQq7_44zNguMiefhxbgGD+-XZxPP@mail.gmail.com> <a06240802c9a7e0807069@10.31.200.117> <AANLkTi=4co5mS3RYhK1BvUMOm54wgNAMeKtk3_Zm0ff1@mail.gmail.com> <a06240802c9a93d762e13@[10.31.200.112]> <a06240803c9a9417e1fe8@[10.31.200.112]> <4D938CC3.1020103@nlnetlabs.nl> <a06240800c9ba6184d535@[10.31.200.112]> <4D94DF2B.1040407@nlnetlabs.nl> <a06240800c9bb6f86edae@[10.31.200.112]> <alpine.BSF.2.00.1104011022030.92106@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 01 Apr 2011 10:28:15 -0400 (EDT)
Subject: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs
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, 01 Apr 2011 14:26:36 -0000

This is a proposed change in DNSSECbis that changes the mandatory 
algorithm rules.  I'm posting this as a summary of what I understand 
some may support; I don't support this change myself. Please post in 
this thread with your support or lack thereof.

For additional operational and zone-signing flexibility, particularly
to allow the publication of a DNSKEY of a new algorithm before a zone
is fully signed with that algorithm, we propose to change these rules
to use ONLY the DS RRset for algorithm signalling, not the DNSKEY
RRset.

Zones will be required to be signed with each algorithm (though not
necessarily eack key) present in the zone's DS RRset or configured
trust anchors.

My opinion:

In retrospect, we probably could have used this mechanism when we 
first wrote these rules -- the choice to use both DS and DNSKEY for 
signalling may have been an artifact of history.  As it is, this 
change may cause zones signed under these new rules to fail validation 
in deployed code, including unbound.  That alone is enough to lead me 
to oppose this change.

-- Sam