Subject: Re: NSEC3 - proposed mods to draft

From: Roy Arends <[email-masked]>
Date: Sun, 25 Jun 2006 04:44:15 +0200

"David A. Wheeler" <[email-masked]> wrote on 06/23/2006 05:24:28 
PM:

> I know you're trying to meet a Monday deadline for NSEC3.
> Here are a few proposed _specific_ changes to the spec, which I've
> tried to make as easy as possible for you; they're basically line-
> in/line-outs;
> I hope they help:
> 
> * Nit - section numbering is wrong - in May draft, 11 precedes 10..
> need to renumber in order..!

We've done a total rewrite since then, so this was already fixed.

> 
> * Under "Security Considerations":
> - Change "DNSSEC already relies on SHA-1 to not collide" to
> "DNSSEC already relies on the presumption that the
> cryptographic hash function (such as SHA-1) will not collide."
> (other hash functions besides SHA-1 are possible, in the long term 
likely,
> and the sentence structure was a little odd anyway.)

This is changed to:

                                 Note that DNSSEC already relies on the
   presumption that a cryptographic hash function is second pre-image
   resistant, since these hash functions are used for generating and
   validating signatures and DS records.

> - After the 1st two paragraphs (discussing iterations and salt), add:
> "Domains can also make discovery of many names much more difficult,
> if ithey wish, by choosing longer names that are not in any dictionary
> and do not follow any discernable pattern.
> They can also insert 'dummy' names that should never be queried,
> possibly including some easier-to-find names, and then alert an 
administrator
> when unexpected queries are performed on those names."

This document describes the workings of the DNSSEC/NSEC3 protocol, and was 
not ment to be an exhaustive list of all possible defenses against 
enumeration.
 
> * Under "Rationale", insert before last paragraph:
> "Some alternatives to this specification have undesirable side-effects.
> An unsigned reply denial of existence can be trivially spoofed.
> Ignoring requests for non-existant names blurs the important distinction
> between packet loss due to network overcommit/outage,
> packet loss due to intentional targetted attack,
> and assertion-of-nonexistence, resulting in
> excessive useless retransmissions and effective lack of authenticated
> denial of existence.
> Signing a denial of existance for each specific name requires that 
> the name server
> have a private key for denial of existence; its subversion
> could then result in large-scale denial of service. Some may find this
> last result an acceptable tradeoff, but many others will not.
> This specification provides protection against trivial zone enumeration 
while
> (1) providing signed denial of existence and (2) not requiring 
> private keys in the
> name servers."

> (elsewhere is fine too, of course.  But I think this is important 
background
> information that needs to go SOMEWHERE in the document.  If you don't 
briefly
> document WHY this specification is designed the way it is, the
> reader will wonder why you did NOT do these "obvious" things.
> Paul Vixie noted that "the archives are in complete disarray on this
> topic." :-) ).

We can now refer to:

   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00794.html

:-)

Anyway, the validity or limitations of other proposals (i.e. not specified 
in any draft) should not be listed in this document. It is distracting, 
and basically not relevant for NSEC3. It is fine to have this in a 
seperate 'road map' draft or something similar. We have limitted ourselfs 
to solely list the limitations of NSEC3.

> * Add "It is RECOMMENDED that master servers cache a few recent queries 
that
> resulted in not-found results, to save processing time"
> (I reworded the last part).
> 
> Here is the proposed changed I noted earlier:
> * section 10, in the phrase "cannot by cryptographically proven",
> replace "by" with "be".

Fixed.
 
> To address NSEC3 issue 10, in the security section note the issue 
> and specifically
> tell the implementors it's okay to drop requests for nonexistent names 
if they
> have to, to serve existing names (it's a DoS, but it at least limitsthe 
damage
> and is better for most people, so it should be explicitly permitted).
> Here's some sample text, more or less lifted from the earlier emails
> (I just don't want this lost, you probably already have this in the 
draft):
> "Significantly more work is required for a name server to respond to
> queries which require negative proofs using NSEC3 than is required for
> a client to compose and send them.  For each such query, the name
> server must repeat the hash function for the number of iterations
> specified in the NSEC3 RRs.  Consequently, name servers with NSEC3
> zones are susceptible to asymmetric DoS attacks.
> Implementations MAY provide a reduced
> quality of service for queries which require negative proofs, so that
> resolution and validation of existing names will not be compromised."
> (In earlier text I said RECOMMENDED... I think that might be a good idea
> to recommend, but that's very debatable so I leave it up to you.  But 
telling
> implementors they at least MAY drop them if necessary is, I think, 
important).

Will chew on this. 
 
> I look forward to seeing the new NSEC3 spec.  I agree with adding the
> hash length field, though that will obviously require a (small) change 
in
> implementations... best to find that out NOW than after it's an RFC...! 
:-).

Thanks for reading the draft !

Regards,

Roy

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