Re: [secdir] SECDIR review: draft-ietf-dnsext-dnssec-rsasha256

Andrew Sullivan <ajs@shinkuro.com> Wed, 23 September 2009 14:04 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34083A6905; Wed, 23 Sep 2009 07:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 zE0nwGrDbTQT; Wed, 23 Sep 2009 07:04:01 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D83B63A659A; Wed, 23 Sep 2009 07:04:01 -0700 (PDT)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 56B1B2FE8CE3; Wed, 23 Sep 2009 14:05:07 +0000 (UTC)
Date: Wed, 23 Sep 2009 10:05:05 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
Message-ID: <20090923140505.GP4450@shinkuro.com>
References: <alpine.BSF.2.00.0909101523400.54991@fledge.watson.org> <9E513A07-3BE5-4D49-9BD9-211CBF0724CC@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9E513A07-3BE5-4D49-9BD9-211CBF0724CC@isode.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: draft-ietf-dnsext-dnssec-rsasha256@tools.ietf.org, dnssec-chairs@tools.ietf.org, The IESG <iesg@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review: draft-ietf-dnsext-dnssec-rsasha256
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2009 14:04:02 -0000

Hi,

Thanks for your review.  I apologise for not having responded sooner.
I was travelling on other business last week, and it meant that I
couldn't concentrate on this topic.  One note of explanation:

On Wed, Sep 16, 2009 at 10:12:25AM +0100, Kurt Zeilenga wrote:

> I do note that the document appears to place an additional  
> recommendation upon implementors of DNSSEC (in Section 5.1) yet does not 
> "update" any DNSSEC specification.   It may be appropriate for this I-D 
> to "update" (upon approval/publication) DNSSEC specifications.

We have been loathe to make this document the mechanism by which we
update the DNSSEC specifications effectively to make NSEC3 an overall
part of the DNSSEC specification.  The reason I (especially) have been
so reluctant is that we already have, in the DNS community, a long
history of complaints about apparently minor, tangential drafts making
major conceptual changes to the DNS specifications.  The idea is to
ensure that the change making NSEC3 a basic part of DNSSEC appears in
a document that is obviously about DNSSEC as such, and not just the
identifier of an algorithm that may or may not get implemented.

We in fact have a draft in process that is to contain this change.
It's draft-ietf-dnsext-dnssec-bis-updates.  It has been moving
somewhat slowly through the WG, but I believe it is on track to be
published soon.  The current text in that document is this:

2.1.  NSEC3 Support

   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
   records for hashed denial of existence.  Validator implementations
   are strongly encouraged to include support for NSEC3 because a number
   of highly visible zones are expected to use it.  Validators that do
   not support validation of responses using NSEC3 will likely be
   hampered in validating large portions of the DNS space.

   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

All of that said, if you feel strongly that, in the absence of
publication of dnssec-bis-updates, the sha-2 draft ought to update
RFC4033, we can relucantly make the change.  In that case, we will
plan to leave the above text in dnssec-bis-updates anyway, in an
effort to make this point plain to a potentially wider audience.

Best regards,

Andrew (shepherd)

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.