Re: Redux: Why I want to remove the null key (SIG)

Roy Arends <roy@nlnetlabs.nl> Wed, 14 June 2000 16:31 UTC

Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27364 for <dnsext-archive@lists.ietf.org>; Wed, 14 Jun 2000 12:31:48 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FX7-000O32-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:56:49 -0700
Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FX6-000O2w-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:56:49 -0700
Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FX6-0000dE-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:56:48 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Jun 2000 15:39:06 +0200
From: Roy Arends <roy@nlnetlabs.nl>
To: namedroppers <namedroppers@ops.ietf.org>
cc: Edward Lewis <lewis@tislabs.com>
Subject: Re: Redux: Why I want to remove the null key (SIG)
Message-ID: <Pine.BSF.4.21.0006141506170.30682-100000@open.nlnetlabs.nl>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Fri, 9 Jun 2000, Edward Lewis wrote:

> In the parent zone:
> 
>          child    NS
>          child    KEY  null
>                   SIG  KEY ...
>                   NXT
>                   SIG  NXT
> 
> In the child zone:
> 
>          child    SOA
>                   SIG  SOA
>                   NS
>                   SIG  NS
>                   KEY
>                   SIG  KEY (signed by Mars Certification Agency)
>                   NXT
>                   SIG  NXT

The child zone is more authoritive than parent when it comes to
child-info.

As this child has a KEY, which is validated off-tree, a secure entrypoint
is defined here (as explained in our remarks on the
draft-ietf-dnsext-zone-status-01.txt). The resolver of interest for this
secure branch has the Mars Certification Agency KEY pre-configured and
knows that this is a secure entrypoint.  Therefore this secure resolver
can positively validate the SIG(KEY) at the child.

> This was legal under the policy in RFC 2535, section 6, but is not legal
> given the updating draft.

Which draft would this be ? 
  draft-ietf-dnsext-simple-secure-update-01.txt,
  draft-ietf-dnsext-signing-auth-01.txt or
  draft-ietf-dnsext-zone-status-01.txt. 

> According to 2535, the credibility of the
> child's KEY would force a "hiding" of the parent's NULL key, and
> certification chains would be formed to the certifying authority.  The
> Signing Authority does not account for off-tree certification, not at
> least until we understand it better.

According to 2535 there MUST be a NULL key signed by the parent in this
case. This is also needed to prevent denial of service for this
child for security aware resolvers, that are not preconfigured with
the Mars Certification Agency KEY and corresponding entry-points.  
Of course, for these resolvers, the child is seen as unsecured.

IMHO this doesn't say anything about the NULL key being a bad idea.

--roy & ted





to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.