Re: draft-arends-dnsnr-00

[Ben Laurie <[e-mail]>]

Roy Arends wrote:
> 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.

I do not propose that NSEC2 should _replace_ NSEC, I propose that an 
operator can choose which of the two record types is supported.

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

I am not wedded to the idea that the whole owner name should be hashed, 
but there are at least two considerations here:

a) Hashing individual labels will make the records _much_ bigger.

b) EXIST is only needed if the zone is more than one name deep (i.e. 
names within the zone contain dots), which strikes me as a rare situation.

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

Of course, you can set it to 1 in NSEC2 if you believe this.

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

NSECINFO does not appear in NSEC2-01.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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