Re: draft-arends-dnsnr-00

Roy Arends <roy@dnss.ec> Mon, 26 July 2004 08:43 UTC

From: Roy Arends <roy@dnss.ec>
Subject: Re: draft-arends-dnsnr-00
Date: Mon, 26 Jul 2004 10:43:00 +0200
Lines: 58
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.BSO.4.56.0407121709550.12231@trinitario.schlyter.se> <20040726094709.1ddf51a9.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Jul 26 11:06:28 2004
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: roy@trinitario.schlyter.se
To: "Olaf M. Kolkman" <olaf@ripe.net>
In-Reply-To: <20040726094709.1ddf51a9.olaf@ripe.net>
Precedence: bulk
X-Message-ID:
Message-ID: <20140418071904.2560.45659.ARCHIVE@ietfa.amsl.com>

On Mon, 26 Jul 2004, Olaf M. Kolkman wrote:

> I would have liked to keep this genie in its bottle but it occurs that
> Roy's proposal is a mixture of NSEC2 and OPT-IN specs. I would say
> that the same security properties of OPT-IN apply to the Roy's
> proposal.

The NSEC2 specs in my proposal are different, but in general, yes, hashed
names and OPT-IN.

> I.e. the record provides proof that a certain part of the
> namescpace is insecure. In that part of the insecure namespace you can
> happily spoof names away or spoof a microzoft.com response.

Opt-in is an option.

> If we want to have both obscured names and "non-secured" intervals in
> your zone, so that during initial deployment you only have to create
> and sign a handful of NSEC variants than Roy's proposal is worth
> investigating.
>
> If you want a choice between "fully  secured" zone with obfuscated NSECs
> and a zone with "insecure ranges" with obfuscated NSECs than NSEC2 with
> an "OPT-IN" type flag seems to be the way forward.

I don't understand what you are suggesting, since you start with the
notion that NSEC3 is a mixture of NSEC2 and OPT-IN, and you end with the
notion that NSEC2 with OPT-IN is different then NSEC3 (If/If).

Leaving opt-in aside for the moment, lets compare NSEC2 and NSEC3.

NSEC3 is backwards compatible with NSEC (using hash value 0), allowing
operators to first switch to DNSSEC-ter at some point in time, and after
that, whitch to hashed ownernames. NSEC2 is either-or. There is no bw
compatibility with NSEC2. If an operator wants to switch to plain labels,
not only does it need to switch to NSEC, also it needs to switch to
DNSSEC-bis.

NSEC3 does not 'flatten' empty-non-terminals, where-as NSEC2 emulates
empty non-terminals with an extra EXIST record type. This is because NSEC3
hashes individual labels, where NSEC2 hashes owner-names.

NSEC3 does not include 'hash-iterations' since the gain in obscuring does
not outweigh the additional cost in authoritative nameservers.

In general, the purpose of both records are the same: increase the cost of
zone-enumeration.

NSEC3 has NSEC2 properties. Additionally it is bw compatible with NSEC,
allows OPT-IN and does not need extra records like NSECINFO and EXIST.

Roy

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>