Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Dec 2005 10:37:09 -0500

At 15:13 +0000 12/5/05, Geoffrey Sisson wrote:

>Note that -ietf-dnsext-dns-name-p-s has been requested for publication
>as Experimental, so it's not part of the protocol.  The described
>methods are provided as an aid to implementors and are not normative.

I hate dropping into document politics as a backdrop for a technical 
discussion.  I mean, I just wanted to re-express the original intent 
because I think the solution is more complicated than it need to be.

>The "modified method" would be quite broken for some types of zones,
>e.g. ones with lots of deeply-nested empty non-terminals.  For example:
>
>     $ORIGIN 5.6.8.1.4.4.e164.arpa.
>
>     1.1.2.2.3.3 IN NAPTR <blah>
>
>     9.9.2.2.3.3 IN NAPTR <blah>
>
>     . . .
>
>When using the modified method, a query with a QNAME of
>4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa. would produce this response:
>
>     2\255{62}.5.6.8.1.4.4.e164.arpa. IN NSEC 3\000.5.6.8.1.4.4.e164.arpa. ...
>
>This would potentially deny the existence of quite a few existing DNS
>names, substantially increasing it's utility for replay attacks.

The question isn't exactness, it's simplicity.  E.g., in the example 
you raise, enumeration isn't an issue, so I'd say it's a bad example 
to use in the sense that it isn't a realistic dilemma.

The essence of my comment is that the attempts to remove 
enumerability from DNSSEC mean "violating" assumptions made in the 
decision tree [1] used long ago to arrive at the NXT record.  I don't 
mean to infer that the decision tree is sacrosanct, but that the path 
then chosen was the least intolerable.  Going back on that has two 
options - deciding than a discarded option wasn't so bad or 
approximating something.

I see this, sometimes called "white lies" as being an approximation 
of the zone's contents to throw off would-be enumerators.  Being an 
approximation, there will be in accuracies.  The question isn't 
whether there are, but whether the inaccuracy will cause a problem. 
I.e., so what if I say that for x.example, there is nothing from 
t.example to z.example, yet if you ask for y.example, I answer with 
that data.  Yeah, a replay is possible.  I'm sure you can run through 
the options (tighten up the denied space, give the real space, return 
to signing the SOA).  Do you think that a more exacting approach will 
payoff per unit of effort to get there?  Maybe so, I'm just 
commenting.

[1] - 
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html, 
not an authoritative rendition of it, but that is what I think the 
decision tree was.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Dec 2005 08:04:33 +1100

> Edward Lewis <[email-masked]> wrotes:
> 
> > At 10:53 -0500 11/22/05, The IESG wrote:
> > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt
> > 
> > #   This document describes two methods:
> > #
> > #   1.  An ``absolute method'', which returns the immediate predecessor
> > #       or successor of a domain name such that no valid DNS name could
> > #       exist between that DNS name and the predecessor or successor.
> > #
> > #   2.  A ``modified method'', which returns a predecessor and successor
> > #       which are more economical in size and computation.  This method
> > #       is restricted to use with zones consisting exclusively of owner
> > #       names that contain no more than one label more than the owner
> > #       name of the apex, where the longest possible owner name (i.e. one
> > #       with a maximum length left-most label) would not exceed the
> > #       maximum DNS name length.  This is, however, the type of zone for
> > #       which the technique of online signing is most likely to be used.
> > 
> > I have two comments to make on this.
> > 
> > One is that I think it's unwise to design a standard part of the 
> > protocol based on the data content of the zone.  I'm referring to the 
> > sentiment in the last sentence of the quoted section.  This is not a 
> > concrete comment, just a design guideline, and it is less important 
> > than my next comment.
> 
> > Keeping in mind that we discourage (or should, I recall talking about 
> > this) caches from being used to speak authoritatively about data and 
> > the behavior of negative caches, does it really matter if the NSEC 
> > contents are "true?"  Especially when what is "true" can change with 
> > dynamic update.
> > 
> > My point here is, perhaps the modified method is all that is needed, 
> > regardless of the kind of data in the zone.  Can we get away with one 
> > approximately good method instead of having to define two exacting 
> > methods?  Can't we simplify this?
> 
> Geoff
	It's also a waste of time using it on such a zone as it is
	easy to reconstruct the contents even using whitelies as it
	has too much structure.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]