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

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Dec 2005 16:18:35 -0500

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.

Back in the times of the first DNSSEC definition, the reason that the 
NXT records listed two names in the zone was to limit the benefit of 
replaying the NXT records do deny other names.  At the time, a common 
practice in answering negatively was (and is) to include an SOA 
record.

Simply signing the SOA record and returning that accomplishes the 
goal of source authenticity.  But it leaves open the vulnerability of 
the replay attack.  That is why the NXT limited the span of names.

The span of names in the NXT wasn't meant to expose the contents of 
the zone.  The span of names was meant to cut down the replay attack 
damage.  That names in the zone were used was for convenience, and 
because it gave us names to use in pre-computing (off-line signing) 
all of the needed negative answers.

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?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Geoffrey Sisson <[email-masked]>
Date: Mon, 5 Dec 2005 15:13:31 GMT

> concrete comment, just a design guideline, and it is less important 

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.

> methods?  Can't we simplify this?

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.

Geoff

---

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

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

>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

---

From: Geoffrey Sisson <[email-masked]>
Date: Mon, 5 Dec 2005 18:02:15 GMT

> because I think the solution is more complicated than it need to be.

Hi Ed,

This was in response to your comment:

> I think it's unwise to design a standard part of the protocol based on
> the data content of the zone.

It was simply to clarify that the methods described in
draft-ietf-dnsext-dns-name-p-s are not part of the NSEC epsilon
protocol, but are implementation details that may be disregarded
without protocol violation.  The NSEC epsilon protocol is defined
solely by draft-ietf-dnsext-dnssec-online-signing.  I'm not sure
how I was invoking document politics by attempting make this
clarification.

> >     9.9.2.2.3.3 IN NAPTR <blah>

[snip]

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

You may prefer this real-life example:

We at Nominet maintain a zone for the sch.uk domain with the following
structure:

$ORIGIN sch.uk.

<school>.<locality> IN NS <nameserver 1>
<school>.<locality> IN NS <nameserver 2>

e.g.:

------------------------ Begin included text ------------------------

. . .

appleton.oxon	IN	NS	ns0.netcentral.co.uk.
appleton.oxon	IN	NS	ns1.netcentral.co.uk.

aston-and-cote	IN	NS	ns0.netcentral.co.uk.
aston-and-cote	IN	NS	ns1.netcentral.co.uk.

. . .

------------------------- End included text -------------------------

For a query with QNAME asbo.oxon.sh.uk., using the modified method
would result in this NSEC RR:

    oxom\255{59}.sch.uk. IN NSEC oxon\000.sch.uk. NSEC RRSIG

The response could then be used to deny the existence of any of the
300+ DNS names in the oxon.sch.uk. domain.  In fact, the existence of
_any_ desired DNS name in .sch.uk could be trivially denied by
generating a suitable QNAME and then replaying the result.

> decision tree [1] used long ago to arrive at the NXT record.

I think this more a comment on draft-ietf-dnsext-dnssec-online-signing
than on draft-ietf-dnsext-dns-name-p-s (which is a supporting document
for the former).

>                                                            Being an 

I hope I've been persuasive that the use of the "modified method" with
some zones will result in unacceptable inaccuracies, which is why it's
not the only one presented.

Geoff

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Dec 2005 14:01:04 -0500

>not the only one presented.

I wonder if the modified method needs to be documented so thoroughly 
then.  I mean, if this is meant to be a guide to implementers of 
general purpose code, how do they make use of it?  Would they 
interpret the document as saying "if you support this experimental 
specification, you use the modified if the zone is one-label deep 
else you have to do the other method?"

I probably should read the front matter again to see how this 
suggestion is motivated.  (I say this instead of just doing it 
because of other time commitments.)  I was looking mostly at the 
"guts of the science" last time.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Geoffrey Sisson <[email-masked]>
Date: Mon, 5 Dec 2005 20:41:48 GMT

> else you have to do the other method?"

That's one possibility.  Another is that they simply implement the
absolute method alone.

The modified method is an optimisation aimed principally at "delegation
only" zones with no non-terminals, such as those typically managed by
TLD registries.  (This is described in Section 1.2 of the draft.)  Thus
the modified method might be employed only in specialised
implementations for this specific use.

Geoff

---

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

> names, substantially increasing it's utility for replay attacks.
	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]