Subject: Proposal to fix NSEC

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 12:35:44 +0100

I understand this draft comes very late in the day, but it is also my 
understanding that it addresses a very crucial issue for registries in 
the EU and possibly other regions: their obligation to protect 
registrant data.

I am sure that this will cause discussions of both a technical and 
political nature. I would like to make it clear from the outset that my 
comments on technical matters are on behalf of Nominet, but political 
comments are my own - I am not empowered by Nominet to discuss policy 
issues on their behalf.

I know that many of you will be at the DNSSEC deployment workshop in SF 
on Sunday - both Geoffrey and I will be there and will be happy to 
discuss this draft with anyone who is interested.

http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt

I will, of course, be submitting this to the I-D editor, but because of 
the nearness of Sunday I thought it best to post it now.

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

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 19 May 2004 15:16:09 +0200

[Quoting Ben Laurie, on May 19, 15:02, in "Re: Proposal to fix  ..."]

> [email-masked] wrote:
...
> > 	I guess that I remain unconvinced.
> > 	What -registrant- data is stored in the DNS?
> > 	In most cases, -registrant- data is stored in
> > 	some whois-like database.
> 
> NSEC provides an index to whois.

That is correct: the whois data is the (privacy legislation) problem,
and being able to walk the tree exposes this problem even more, and
certainly makes it more visible.

However, "fixing NSEC" will not fix the real (whois) problem.

-- teds

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 14:48:36 +0100

Scott Rose wrote:
> Just did a quick first read -
> 
> Is the NSECINFO RR really necessary?  It seems redundant to me and just
> another RR/RRSIG combo to be placed in the additional section for a negative
> response.  The hash ID could be the first field in the NSEC2 RDATA (just
> like in DS, RRSIG, etc) - no need for another record to store that.  The
> iterations could be stored there as well, but I don't know how useful it is
> to begin with.

Sure, the reason I stored it as a separate record was because of 
redundancy, since it has to be the same for the whole zone, but it might 
indeed make more sense to include it in NSEC2.

> Why is it 3 octets long (odd number btw)?

2 was too few, in my view.

> Couldn't it
> become a DoS attack vector by a malicious or silly admin setting the number
> arbitrarily high?

Yes, I noted that somewhere, implementations should probably just fail 
for values locally considered to be too high.

> I also fail to see the use of the salt value in the NSECINFO.  The draft
> states it is there to prevent dictionary attacks.  Couldn't an attacker
> could just get the salt, and then perform the attack?

Its to prevent precomputed dictionary attacks (this is explained in the 
security considerations). This matters if your zone is worth rescanning 
frequently.

> I would recommend dropping the NSECINFO RR altogether and move the digest
> code and the iterations (though shortening the field to 2 octets) into the
> NSEC2 RDATA.  Although I wouldn't mind dropping the iterations field as
> well.

I would have no strong objection to moving it. I'm not sure I believe 2 
octets is sufficient for iterations, and I don't think dropping 
iterations is a good idea, since that is how you choose the cost of 
dictionary attacks.

Cheers,

Ben.

---

From: [email-masked]
Date: Wed, 19 May 2004 16:39:18 +0200 (CEST)

On Wed, 19 May 2004, Marcos Sanz/Denic wrote:

> Roy,
>
> > We've already done this 3 years ago and I see no reason in bringing this
> > back.
>
> With all my respects, the reason is on the table:
> the NSEC traversal problem to be fixed within DNS.

NSEC traversal will still exist. hash by hash. Using NSEC2 the attack
vector is shifted. From an online dictionary to DNS attack, to an offline,
dictionary to NSEC2-hash attack.

An obscured circular list is still a circular list. Getting rid of the
circular list is a better solution imho, but that has other issues like on
the fly signing. private-key stored on an online-box, etc.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2004 14:33:42 +0000

> However, "fixing NSEC" will not fix the real (whois) problem.

i agree with ted.  dns is a publication mechanism, and if you don't want
something published you probably shouldn't be putting it into dns at all.
and, if your only way to keep whois safe is to hide its index, then you
have probably got other troubles.  parts of the "index" are exposed every
day in server logs or in-addr.arpa/ip6.arpa walks.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:13:01 +0100

Jim Reid wrote:

>>>>>>"Ben" == Ben Laurie <[email-masked]> writes:
> 
> 
>     >> still possible, hash by hash. An offline dictionary attack
>     >> (remember that the NSECINFO trick does not work) does the
>     >> rest. To speed things up, you could brute-force labels with
>     >> length up to 5 or 6 characters.
> 
>     Ben> If we made hashes take, say, 10 ms to compute, then this
>     Ben> attack would take nearly a year. This is the point, surely?
> 
> Ever heard of Moore's law? 

Indeed I have, which is why iterations is a tunable parameter.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:59:01 +0100

Scott Rose wrote:
> I'm trying to fit the EXIST RR into the NSEC response cases in
> draft-ietf-dnsext-dnssec-proto.  I think I understand how the NSEC2 and
> EXIST combos would work.
> 
> Only case 2 (no name, no wildcard) would be affected.  However, could it be
> possible to do a EXIST walk of a zone?  If EXIST RRs exist at every
> authoritative name in the zone, it is possible for an attacker to do the
> same sort of walk just in reverse.

To be clear, EXISTs only exist where no other RR exists, but I don't 
think that changes your point.

> For example:  in the response in the draft, what if an attacker then queries
> for "a.b.b.d.e IN A" or similar?  assuming they they get a negative answer
> again, a new closest encloser is given (and another point in the namespace).

Clearly, if they want to know whether one of b.b.d.e, b.d.e, d.e or e 
exists, it is only a little more expensive to just ask than to discover 
it by being handed the EXIST record. Paricularly since in practice it is 
almost always true that the closest encloser will be the name with the 
first element removed, and will already be known to the attacker.

Cheers,

Ben.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 14:56:53 -0400

> -----Original Message-----
> From: Ben Laurie [mailto:[email-masked]]
> >

Then I don't believe I understand where the EXIST RR would be in a zone.
For example, in a flat zone (all authoritative names in the zone are
"<some_label>.example.com." and no wildcards.  Is there only one EXIST RR
(saying "example.com  IN EXIST"), or multiple?  Or is generated and signed
on the fly?

Bringing back Roy's comment on the wildcard clarification and the DNSSECbis
protocol draft, I think Sections 4 and 5 would need to be updated.
Specifically, the response in the example in section 5 would not need NSEC2
RRset (b).

Scott

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 20:47:10 +0100

Scott Rose wrote:

>>>Only case 2 (no name, no wildcard) would be affected.  However,
>>
>>could it be
>>

There would be none, since, presumably, there would be at least one 
other RR for example.com (e.g. SOA).

It is absolutely not generated and signed on the fly.

> Specifically, the response in the example in section 5 would not need NSEC2

Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2?

Cheers,

Ben.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 15:54:08 -0400

> Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2?

Sections 4 and 5 in the NSEC2 draft first, the eventually the DNSSECbis
docset if NSEC2 is adopted.   With the wildcard clarification work Ed Lewis
started a while back, it makes it easier to understand wildcards and denial
of existance responses.

Scott

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 15:06:53 +0200

Bob Halley <[email-masked]> wrote:

> The problems with online signing are:
> 
>         It's a CPU burden for the authoritative nameserver.

Yes, but the operators in question (TLD registries) should be able to deal
with this.

>         You must trust your slaves enough to give them the right
>         to make signatures.  In the standard DNSSEC model, a
>         rogue slave can deny service, but it cannot generate
>         authenticated zone content.

Most TLDs already have all their nameservers under their very own control
(although not necessarily on a physical level). So betrayal by 2ndary isn't
a problem. For cases where one of the servers is compromised, DoS is possible
even with DNSSEC because an attacker would be able to provide for forged
signatures. The risk of forged entries can be reduced by using different
keys. The offline key would be used to sign RRSets, securing positive responses
(mostly DS RRs). The online key could be used to sign online NSEC RRs to
be generated on the fly (and pointing at some uncritical, maybe not even
existing name). It's just that I don't see an opportunity to signal this
distinction at the moment.

-Peter

---

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 20 May 2004 12:49:00 -0400

> > The problem is that [online signing is] just too prone to
> > DoS attacks....   Which is BAD.
> 
> A standard could be established to help thwart DoS attack.
> 
> 1) Only use signatures for queries from named name servers 
> (ns record exists).

This blatantly ignores the completely common case where
the set of recursive/caching/resolving nameservers for an
organization are separate from the set of authoritative
nameservers (with NS records for the zone delegation)
for that organization.  As a result, your notional standard
is not likely to work.

  --Rip

---

From: "Sal Mangiapane" <[email-masked]>
Date: Thu, 20 May 2004 13:09:44 -0400

> for that organization.  As a result, your notional standard

This is exactly what each group would need to establish.  In this case, what the criteria for DNS would be.

The Internet benefits from the ubiquity of DNS.  Couldn't the same be true for a single system of digital signatures?

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 22:00:19 +0200

Andras Salamon wrote:

> How many times does this need to be repeated?

try until it's true. I'd really appreciate if people wouldn't generally
neglect any difference between every single record of data (or a set of data)
being public (i.e. accessible anonymously without any further authorization)
and all of the data being accessible at once. There is a difference and
we have several examples, whois itself being one of it. Another are "public"
phone directories allowing for name to number mappings but not for bulk
transfer or "reverse mapping". (Commercial) databases of other kinds come to
mind. So, just repeating over and over again that "public" is "public"
doesn't lead us anywhere.

Now, back to DNS, it may well be that it wasn't designed to protect the
zone(s) from being XFRed, but there are other things it wasn't designed for,
too (like being a flat keyword index). Again, AXFR doesn't constitute a
technical or security problem per se. Of course that's a layer 9 problem,
but so what? Isn't DNSSEC as a whole there to solve layer 9 problems?
If the world weren't so bad, we wouldn't need any security protocols.

Now, for AXFR blocks not being standardized: REFUSED does exist. There's
no (longer a) DNS way to communicate between master and slaves the necessary
authorization info, but that doesn't prove anything more than you cannot rely
upon it (unless you have out of band communication).

I believe DNSSEC is necessary and I want it deployed - without a major
protocol redesign which would cost more time than available - given that
there are other protocols in the queue which kind of need a secured DNS.
But here's a deployment obstacle which has come up really late (well, NO
was worked on a few years ago, but the problem wasn't emphasized back then)
and which needs an engineering solution. Can we work on one?

-Peter

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 22:36:45 +0200

Dear Colleagues,

Let me try and sumarise what I've seen so far and suggest a way
forward.

Ben proposed a mechanism to fix "NSEC zone traversal" that apparently
hinders TLDs in the deployment of DNSSEC. Although the discussion on
the validity of this reason is interesting it is not a protocol issue. 
We
will not be able to change TLD policies.

The proposed mechanism, I'll refer to is as NSEC2, may have technical 
merit.
I think it is fair to say that the working group is still digesting the 
technical
details of the proposal. Please continue to do so, having documented 
why a
technology will or will not work is a good thing.

As far as I understand the security properties of the proposed
technology are such that changes are needed to the protocol as in
DNSSEC-bis. This means that we have to introduce a flag day. That flag
day either is "now" or after the DNSSEC-bis protocol is out in the
field.

We as a working group have a choice.

- We take up this NSEC2 proposal as a working item.

   If we do so we will have to merge the technology into the current
   DNSSEC-bis document set. Having a flag day, after introducing
   DNSSEC-bis just does not make sense.

   Realize that taking up this as a working item would result in an
   unknown delay of getting the DNSSEC specifications done. Not only
   will the WG need time to assess the quality of the proposed
   solution but people currently funded to work on the effort may see
   that funding stop and walk away. Realisticly we are looking at
   significantly more than 6 months [*] delay. (We'll have to assess
   interaction with wildcards and other DNS elements. We'll have to
   test for corner cases, &c, &c). There are more pessimistic scenarios
   than the 6 months scenario.

- We do not take up NSEC2 as a working item

   This would not imply that the "NSEC zone traversal" is a non-issue.
   It may actually hinder deployment of DNSSEC some TLD zones.

   If we go this route we may have a proposed standard and start of
   deployment in some zones this year in less than 6 months [*].

   The DNSSEC-bis document set is clear on the fact that DNSSEC does
   not offer privacy. We just have to live with that.

I'll be tracking the discussion with the following in mind.

If I do not see rough consensus on taking up NSEC2 as a work item by 
June 1
I'll reject this as a work item.

If, after June 1, there is consensus on taking up NSEC2 as a work item
I'll try to make an inventory on how many participants of the working
group can commit resources to make this work. If it turns out we
cannot produce standards, documents and code on a reasonable time or
we alienate a significant fraction of the people that are now
committed on working on this we'll also not take NSEC2 up as a work 
item.

If we'll take NSEC2 as a work item then - in order to avoid a flag day -
the current DNSSEC-bis doc set will be put on hold until NSEC2 is cooked
enough to be merged into the DNSSEC-bis documents.

Olaf Kolkman
DNSEXT Co-Chair

(Olafur is away from keyboard for a week or two.)

[*] I've been telling people that DNSSEC will be ready in 6 months
    over the last 3 years. As a result the combination of "6 months"
    and DNSSEC in one sentence rises suspicion.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 23:23:40 +0200

Forwarded message 1 out of 2 (there where problems posting)

> From: Paul Vixie <[email-masked]>
> Date: May 19, 2004 4:33:42 PM CEST
> To: [email-masked]
> Subject: Re: Proposal to fix NSEC
>
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 20 May 2004 16:57:54 -0700

Interesting.

I am trying to work out the reason for the hash iterations.

Let us call the set of names in the zone 
	D = {d0, d1, d2, d3 ... dn}

The problem is to be able to enumerate the inverse of the set
	D' = { ]d0-d1[, ]d1-d2[ ... ]dn-d0[ }

It suffices to present one member of D' to prove that any given domain is
not a member of D.

To describe a member of D we simply specify dx, dx+1

So what you are saying is that we do not need to deal with D, we can apply a
one way function...

	HD = {H(d0), H(d1), ... H(dn) }

	HD' = { { ]H(d0)-H(d1)[, ]H(d1)-H(d2)[ ... ]H(dn)-H(d0)[ }

So why do we need to specify more than H(dx), (H(dx+1)) ???

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2004 12:34:35 +1000

> Robert Elz <kre <at> munnari.OZ.AU> writes:
> 
> > ps: the section in question in the security considerations shouldn't be
> > there at all - not just the final sentence of it, the whole thing.   There
> > is no security implication in being able to find out the names in a DNS
> > zone file.   That's the point of the DNS.
> 
> There can be security implications in finding out names of hosts in a domain,
> without knowing the names in advance.  See for instance:
> 
>   Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in
>   Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT
> ,
>   June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf
> 
> Yes, the attack requires weaknesses in other applications, but the point is t
> hat
> access to the information about names in a domain, acquired via zone transfer
> s,
> helped an attacker.  This still holds, for new not yet public weaknesses in
> various applications.

	It also demonstrates that there are security implications for
	*not* knowing all the names and attached data in advance.

	If you want to allow rlogins from a namespace you have to have
	a local copy of that namespace.  This was a case were allowing
	AXFR *fixed* part of the security issues as it allowed you to
	get the local copy.

> Perhaps core of the problem is to realize that public data, handled in some
> ways, can become a privacy or security issue, however paradoxical it may soun
> d
> at first.  A nice write-up that expand on this theme is:
> 
>   http://www.cs.uwyo.edu/~rex/privacy.html
> 
> Regards,
> Simon
> 
> --
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Sal Mangiapane" <[email-masked]>
Date: Thu, 20 May 2004 22:47:25 -0400

> > nameservers 

These DNS servers can receive a trusted response but could not respond
to the originating request with a trusted (signed) answer.
They can't because they are unknown by authoritative nameservers.
I'm thinking they are outside the chain of trust.
What am I missing?  Will these become obsolete?

Regards,

Sal

Salvatore Mangiapane

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 May 2004 06:02:56 +0100

> So why do we need to specify more than H(dx), (H(dx+1)) ???

To increase the cost of dictionary attacks.

Cheers,

Ben.

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 May 2004 09:54:37 +0100

>>>>> "Roy" == Roy Badami <[email-masked]> writes:

    Roy> If ccTLD operators suggest that this might be an issue for
    Roy> them, then it is IMHO unreasonable for anyone (other than a
    Roy> lawyer versed in this area) to tell them they are wrong.

I don't believe anyone here is claiming they are wrong or that their
concerns about EU directives are invalid. As you say only a clueful
lawyer can make that determination. I do think it's wrong however to
attempt to solve layer 9 problems by redesigning a protocol.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 21 May 2004 13:26:56 +0100

> day in server logs or in-addr.arpa/ip6.arpa walks.

With respect Paul, I think you are handwaving. The wish to have data
published in response to a specific query is not necessarily commensurate
with the wish to have it published under any circumstances whatsoever.
Many people write emails, and thus publish their email addresses. This
does not necessarily mean they want them compiled into lists of email
addresses, associated with other data, and sold as a database.

Current DNS protocol and servers allow a granularity of policy decision on
what gets published, when, and to whom. The currently proposals for DNSSEC
would remove the ability of DNSSEC users to take advantage of that
granularity (i.e. they reduce current functionality that is in use, and
wanted, at least by a significant subset of users)

Whether or not making use of a function that prevents publication of entire
zone files is desirable is a policy question, and not a protocol question.
However, given that the current DNSSEC proposals remove functionality that
is in use (prevention of publication of entire zone files), it's worth a
few of lines describing why removal of that functionality is important.

The problem has been described as simply a legal problem. Whilst indeed
there are EU law considerations, I am aware that the IETF's approach to
legal problems in the past has often been "fix the law"; and indeed, often
rightly so.

However, the problem goes beyond that. In this instance, in my opinion, the
law is merely a symptom of what people want. RFC1591 talks about the local
internet community. In the UK, and the rest of the EU, people are perhaps
more sensitive to privacy issues than they seem to be in the US. Hence, if
you sign up for a phone here, you have the (legal) right to have your
number listed in directory enquiries, but not to have your name included in
a database of names and phone numbers sold to others by the phone company,
and indeed the phone company has an obligation not to distribute the data
for purposes other than those for which it collected it. That legal right
is based on widely held beliefs about privacy. I picked the phone book
example because it's the closest I could find to DNS. And there is a
strongly held local internet community (in an RFC1591 sense) views that
such privacy should continue to apply. See for instance item 8 at:
  http://tinyurl.com/2l59u

I'm posting this rest of this message in a personal capacity, but as a
director of Nominet since it started, and a member of its policy advisory
board, I'll submit the following: the issue of zonefile protection has been
a very significant issue for stakeholders, and an issue on which we
(Nominet) have spent a considerable amount of time and money. And the
reason we've done this is not for narrow commercial advantage, but because
over the past years we've come to realize it's an important matter to the
local community. That's why we are concerned about protocol changes which
remove our ability to do protect zonefiles. My understanding is that
several other ccTLDs have the same concerns for similar reason.

Alex

---

From: Greg Hudson <[email-masked]>
Date: Fri, 21 May 2004 10:24:43 -0400

> attempt to solve layer 9 problems by redesigning a protocol.

So, I don't support modifying NSEC, but this attitude that legal
requirements should never have any impact whatsoever on an IETF protocol
is weird.  You can't "solve" all layer 9 problems at the layer 9 level.

IETF protocols exist to meet people's needs.  People have needs for a
variety of reasons, including the presence of legal requirements.  We
certainly have the right to say "we think this need is bogus, or too
hard to meet, so we're going to punt on it," but to categorically
declare the need out of scope because it's "not technical" is sophistry.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 21 May 2004 16:22:06 +0100

Jim,

--On 21 May 2004 15:11 +0100 Jim Reid <[email-masked]> wrote:

(with apologies for reodering)

>>>>>> "Alex" == Alex Bligh <[email-masked]> writes:
>
> This discussion is getting off-topic for this list which is supposed
> to be about DNS protocol issues.
...
> A discussion about "what people want" is well off-topic for this list.

The protocol issue at stake is the removal of a piece of functionality
(granularity in zonefile protection). I think you agree that much. Whether
or not removal of functionality is acceptable depends on the value of that
functionality. AIUI Your view (and Paul's) is that it is valueless, and
thus removing it doesn't matter. I find it hard to see how you can on the
one hand assert this, and on the other describe as off-topic those
attempting to explain to you the value they have. Functionality does not
exist in an abstract space. What people want from their protocols (what is
useful vs. useless functionality) surely drives what gets included and what
doesn't.

> For instance, by responding to this mail I accept the risk that
> someone may harvest my address and send me spam even though I don't
> want them to do that.

Yep. But I am guessing you wouldn't want psg.com as list operator
to be complicit in it.

> Going back to DNS, I doubt very much if anyone
> registering a domain name in a TLD cares or even realises that the
> whole TLD zone file might be available.

That isn't what they tell us.

>     Alex> That's why we are concerned about protocol
>     Alex> changes which remove our ability to do protect zonefiles.
>
> It's still not clear to me what those concerns actually are and why
> traversing the zone file is such a worry. Maybe I'm just being more
> stupid than usual. As Paul has pointed out, there are plenty of ways
> of enumerating a TLD zone today, with or without some flavour of
> DNSSEC, irrespective of whether zone transfers are possible.

Paul has asserted out that a third party can make a partial, non-shapshot,
list of TLD zonefile contents over months. I don't dispute that. If
I spent three months on it, I bet I could work out a way to steal
a substantial proportion of your possessions. That doesn't make it
either right, or legal, or desirable, for your landlord to decide that
there is thus little point in putting a lock on your door. Despite
the fact that "bad things happen", the zonefile operator does not need
to be complicit in it or make it easier.

> If the
> concern is NSEC records makes whois disclosure easier, then fix whois:
> that's where the personal data lives after all.

> If it's about copyright, the copyright holder's rights should
> still apply.

IANAL but the difference AIUI is that under the proposed protocol, one
would be publishing the compilation (in which separate copyright exists)
oneself.

However, I don't want to reduce this to a legal argument as for me, at
least, that's only one portion of the argument. The fact is (see
references) stateholders in certain ccTLDs do not wish the zonefile to be
published by the ccTLD operator.

> honey trap

Easy enough without DNSSEC.

Alex

---

From: Peter Koch <[email-masked]>
Date: Fri, 21 May 2004 17:39:59 +0200

{responding to Olaf and Ben in one message}

Olaf Kolkman wrote:

> There is no reason why one part of a zone cannot be signed with zone 
> signing key 1 and another
> signed with zone signing key 2. There is no need for signaling.

right, but if both keys are equally applicable a compromised "negative"
key (the one used for online signing) could be used to sign not only fake
negative responses but also fake DS RRs. The first can ``only'' be used
for DoS (leaving aside corner cases of DNS tree walking).
Whether this matters depends on whether one is willing to accept the risk.

Ben Laurie wrote:

> denial of the existence of the particular domain, rather than messing
> with NSEC records. If you had a signed denial, then the easy way to 
> signal it is to have an RR that is specifically for that purpose (that 
> is, when you receive a NOTHISDOESNTEXIST RR you expect it to be signed 
> with the special key used for that purpose alone).

the advantage of "messing with NSEC" is that it's there while any new RR type
needs more work.

-Peter

---

From: Alex Bligh <[email-masked]>
Date: Fri, 21 May 2004 16:57:26 +0100

Paul,

--On 21 May 2004 14:33 +0000 Paul Vixie <[email-masked]> wrote:

>> Actually, I'll take that back, there may be a point in doing more, but
>> there's certainly an argument that suggests that its reasonable to expect
>> not to be in a worse position by virtue of switching from DNS to DNSSEC.
>
> So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess.

I think the issue is that RFC1034 did not mandate, but equally did not
prohibit making zonefiles not enumerable (whether or not that prohibition
is BCP), whereas current DNSSEC does (effectively) prohibit it as NSEC
(which allows the behavior) is mandatory.

>From RFC1034:

	The secondary server must request a zone transfer via an AXFR
	request for the zone.  ** The AXFR may cause an error, such as
	refused **, but normally is answered by a sequence of response
	messages.

Alex

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 21 May 2004 20:38:49 +0200

I see a some of arguments being made about EU concerns over privacy.
The subject whether DNSSEC would be run into EU privacy concerns
pops up on a regular base in various places.

Therefore, SIDN, the Dutch registry, asked for an opinion of the
faculty of law of the University of Brabant. These people, all
lawyers, are specialized in privacy and the influence of crypto
technology on the law (and vice versa). They don't have no specialist
knowledge of the DNS, but know the role it has in the proper working
of the Internet.

I explained them the situation:

	Lots of ccTLDs are preventing zone transfers to be done by
	the public in general often using privacy concerns as the
	primary motif. I also explained that DNSSEC has this back
	door where you can get the names out of the zone by walking
	the NXT records. So the basic question was, is there really
	a concern that this backdoor might prevent the deployment
	of DNSSEC in Europe because of privacy regulation?

Note, this was before NSEC records existed. I'm sticking here to
the term NXT records to stay close to the original conversation.

They were willing to do an small study, and, if they thought that
there might be any problems, they would raise that and then we would
decide whether a larger study was necessary.

It resulted in:
	Tilburg University (B.J. Koops & E. Schreuders), Quickscan
	DNSsec/NXT and privacy, March 2003 (unpublished).

It is not really big, I give here a translation from the Dutch,
leaving out some of the details.

	We don't think that there is a special privacy problem with
	the deployment of DNSSEC caused by the NXT walking which
	would give you a list of names which might be used to query
	the whois service.  The privacy rules are already in force
	by the Wbp (Dutch privacy law, fully implementing the EU
	directives --j) and the regulation of the registry.  (I'm
	skipping the details they quote from court cases and articles
	in our regulations --j).

	DNSsec only offers something new by the capability to get
	a list of domain names. This list is irrelevant from a
	privacy point of view, only the combination with the whois
	database gives the list personal sensitive information (with
	the exception that of domain names such as michaeljfox.com,
	vix.com and jaap-akkerhuis.nl).  Possible problems occur
	when the list is used for interrogating the whois database.
	But for that, there are already existing rules so DNSsec
	doesn't add any problems.

        In short, the back door can give personal data but only
        in combination with whois for which is existing regulation.

Although they don't claim that they didn't do "fundamental research",
We (SIDN) would have been happy to pay for such a study as well,
but they refused, since they thought that such a study would have
a very similar outcome.

So, we concluded that the NXT walking (now NSEC) and (EU) privacy
concerns would not be a show stopper for introducing DNSSEC in the
NL zone.

On this list in this context I noticed that also concernsabout the
IP-rights (Intellectual Property rights) popped up, like one had
on a telephone directory. (There the data is also meant to be public,
but on how it is organized there are IP rights). You cannot just
copy a directory because of that. For a zone file you can claim
this probably as well. That gives you a handle to whack people
making copies. We discussed this internally somewhat.  We think
that IP-rights on a zone file is an interesting idea, but doesn't
prevent zone enumeration. It has more juridical aspects then
technical.

Back to (EU and other) pivacy concerns. Given the fact that there
are multiple ways to do data mining for domain names in a zone as
pointed out by Paul Vixie and Robert Elz, one really must take steps
to limit access to "whois data".

	jaap

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 May 2004 20:31:23 -0700

> attempt to solve layer 9 problems by redesigning a protocol.

I disagree. The ONLY purpose of the protocols is to solve layer 9 
problems. Layer 9 is PEOPLE. 

Roy is stating that this issue is a showstopper for him. Your proposal
is in effect saying that the IETF, an organization with zero internal
democracy and zero accountability should override European Union law
decided by the democratically appointed European parliament and the
council of ministers appointed by the democratically elected European
governments.

Please consider the fact that the IETF claim to be above international
law might just possibly be the result of a ridiculous degree of 
arrogance.

It is a valid point to say that the IETF may not have competence in 
this area, but that may well mean that the IETF does not have competence 
to write any specs whatsoever. if the legal interpretation is an issue 
I suggest that we ask Michael Froomkin or some other DNS savy lawyer
their opinion rather than saying, "I do not understand this issue, 
therefore I will not allow it to be raised."

It seems somewhat strange that people are arguing that the effects
of DNS zone walking are so well understood that no change could
possibly be required. The same people were arguing a little while 
ago that a minor change that would introduce the risk of severe
DNS operational instability should be rejected for the sole reason
that the implication of the change could not possibly be understood.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 May 2004 20:31:22 -0700

> To increase the cost of dictionary attacks.

Ben,

	I think that this risks turning a good proposal into one with a
questionable feature that will distract from the main value. Essentially all
you are arguing for here is an expensive hash function.

	The valud of crypto is that you can introduce asymmetric attack
costs. It is much harder for an attacker to break DES than it is for the
defender to encrypt their message - 2^55.5 times as hard in fact. That is a
real benefit.

	Here you just make the problem harder by an equal factor for
attacker and defender. That is not a core value here.

	Leaving aside that nit, the proposal has real value and adds real
security. The comparative attack analysis that has been offered is totally
bogus:

	The DNS system without DNSSEC provides a lookup function that
returns an answer to the question "is x a member of S" and returns a binary
response.

	With DNSSEC and NSEC you get a response "there are NO members of x
in the range a,b AND a,b are both members of S"

	Sorry, but anyone who claims that there is no security issue raised
here is speaking through their hat. The fact that I publish a binary
response function returning set membership does not mean that I am willing
to reveal the set. That is simply untrue. 

	The number of real world attacks that are made possible by revealing
S is very, very large and very, very significant. I know that there are folk
who dispute this in the IETF, remember however that there are people in the
IETF who have actively discouraged the deployment of firewalls in the past,
and some still do. Regardless of where you stand on that debate please
understand that the fact that if you want to deploy a security protocol it
had better meet the security requirements set by the security establishment.

	In the real world the fact that there is an easy way for an attacker
to discover the names of all my public facing machines is a really really
significant issue. In the real world 95% of attacks are made by people who
are clueless. In the real world security is risk management, not risk
elimination. If you do not believe me on this go talk to Bruce S. or read
Secrets and Lies. 

	In the real world every security incident costs real money. Filters
that catch 95% of the bozos save real money.

	The current NSEC record is bogus. It insists on addressing a
security issue that simply does not exist (securing insecure zones) while
refusing to address a real security issue which is rightly considered by
many to be a showstopper for adoption.

	If there was a logic to the IETF process we would ask people two
questions, first what are the showstoppers that would cause you not to
deploy? second why should we care? I know the IETF lives in a
crypto-communist la-la land where it is impolite to ask such questions but
the failure to do so is the reason that DNSSEC is still a failed spec ten
years on. The canonical texts for my company are Jim Collins, built to last
where facing the brutal facts is considered one key to success.

	My showstoppers are 1) the spec must be incrementally deployable in
large zones and 2) it must address the zone walking issue.

	The reason you should care is that I am one of the very few members
of the security field who has an interest in this group. I am Principal
Scientist of the security division of company that has major influence in
the Security field. I also have personal influence, as the author of XKMS,
and co-editor of SAML and WS-Security I can help convince key constituencies
that they should buy in to DNSSEC.

	The security community is not going to support a spec that
introduces a new security vulnerability that was not previously present and
introduces operational demands that threaten the stability of core DNS. As
the spec stands I cannot recommend it to my colleagues and in fact would
have to recommend that they do NOT deploy.

	With an updated NSEC record that meets the showstopper objections I
describe I will be in a position to recommend DNSSEC. I believe that it is
even possible that with a small amount of appropriate preparation work it
might be possible that MARID and MARID accreditations could serve as a
'killer-app' for DNSSEC. One important political point here is that a MARID
accreditation service would be outside the control of ICANN. Remember that
killer-app means, the app which motivates building the infrastructure, not
necessarily the most important app the infrastructure will serve. Email was
not the Internet killer app, everyone had to be online before it had value,
but now everyone is online email is more important than the web.

			Phill

---

From: Alex Bligh <[email-masked]>
Date: Sat, 22 May 2004 09:55:58 +0100

Paul,

--On 22 May 2004 13:53 +0700 Robert Elz <[email-masked]> wrote:

>   | Roy is stating that this issue is a showstopper for him. Your proposal
>   | is in effect saying that the IETF, an organization with zero internal
>   | democracy and zero accountability should override European Union law
>
> Don't be totally absurd.    As Jaap already showed (after more research
> than the topic deserved), the European laws have nothing whatever to do
> with this ... Incidentally, nor does copyright, which has also
> been mentioned - in order

I'm not going to put privileged legal advice on list (drop me a note
off-list if you like) but suffice to say the old saw about ask two
different lawyers, get two different answers is all the more true in two
different jurisdictions.

For me the point, however, isn't wholly about the law. It's about what
stakeholders want. They do not want ccTLD operators publishing zonefiles.
And ccTLD operators do not want to publish zonefiles. It appears the same
might be true of VRSN. Current RFCs permit non-publication. The current
DNSsec proposal prohibits this. Whether or not all these people are unduly
worried is to an extent a moot question, though personally I agree with
Phillip Hallam-Baker's analysis that more information is revealed.

Alex

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 22 May 2004 06:55:05 -0700

> than the topic deserved), 

What I was objecting to was the assertion that regardless of
whether the law was applicable or not that 'layer 9' is out
of scope.

> the European laws have nothing 
> whatever to do
> with this.   They're designed to protect the privacy of the 
> individual,
> who in this case, has given their domain name to the DNS operator to
> publish - by request (or more likely, by contract, if the data weren't
> published, there might be legal action involved).

The domain name is in many cases a personal identifier. The use 
that the owner has authorized is publication of that data in 
isolation. Privacy law has volumes of case law where a distinction
is made between isolated publication and publication of compilations.

> Incidentally, nor does copyright, which has also been 
> mentioned - in order
> to get copyright protection, the item to be protected has to have been
> published, which is exactly what the organisations that are 
> objecting don't
> want to do, they're trying to keep their list of names 
> secret, which is
> really the anthises of the whole purpose of the DNS.

You are clearly not a lawyer, copyright has not required 
publication since the ratification of the Berne convention
several decades ago.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 22 May 2004 16:15:47 +0100

> attacker and defender. That is not a core value here.

This is true, but neglects the fact that the attacker has to hash far 
more things than the defender. However, an asymmetric solution would be 
even nicer, I'll agree.

Cheers,

Ben.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 22 May 2004 08:09:15 -0700

> more things than the defender. However, an asymmetric 
> solution would be even nicer, I'll agree.

We have a dictionary corpus of n values and perform r iterations.

You are saing that the attacker has to perform n*r work units rather than
only n units and that this is sufficient value to justify increasing the per
lookup work function of client and server from 1 unit to r units.

I still don't see the value. We usually assume that an attacker is likely
to use hardware. 

A dictionary attack is going to work in any situation where you can
perform individual lookups without restriction. That is not the attack
that causes real concern here. What I am concerned with is dictionary
discovery.

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 22 May 2004 22:09:38 -0700

>  From my point of view (speaking as an individual), I am more worried
> about the operational impact of a bunch of knuckle-heads who decided
to
> suck down COM via a NSEC chain walk ...

Basic rate limiting may not prevent enumeration, but it can certainly
mitigate the denial-of-service side-effect of such bone-headed behavior.

-- Christian Huitema

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 07:26:19 -0700

> > ... though personally I agree with Phillip Hallam-Baker's analysis
> > that more information is revealed.
> 
> If he said that, he was wrong.  More likely you misunderstood 
> him.  The same information is revealed, it just happens slightly 
> later and is an indirect activity. 

This shows why DNSEXT should transfer work on DNSSEC to the security
area. 

>From a security point of view more information IS revealled. The
computational difficulty of arriving at an enumeration is significantly
reduced with the DNSEXT. The alternative attack routes suggested
as equivalent are not.

Comparative security analysis is a VERY weak form of argument. 
A huge number of security vulnerabilities result from faulty
comparative argument, in fact it is one of the most common causes 
of security flaws. The errors in WEP were due to that type
of reasoning. 

The IETF has a reputation for designing security mechanisms that
are so completely over-designed that they are undeployable, while
failing to meet security requirements considered critical by end
users. IPSEC refused to address NAT but created a negotiation 
mechanism for key negotiation.

If you want anyone to use DNSSEC then you had better address the
requirements of the security community.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 08:04:13 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
> While I am in no way empowered to speak officially for VRSN, 
> I will say 
> that VeriSign probably doesn't care terribly much about "preventing 
> enumeration", as you can download the zones yourself, if you care to.

I am not speaking for VRSN here officially either.

Registry services may not have a position here. 

Security Services is very likely to form one. Several proposed 
anti-spam and anti-phishing measures use the DNS in a fashion
that could benefit from DNSSEC but not if doing so opened up 
zone enumeration.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 08:32:13 -0700

> SLD holders outnumber TLD holders by a factor of many 
> millions.  As an SLD
> holder I can tell you that I do not fear enumeration as much as I fear
> spoofing.  There are a few SLD holders who hold the opposite 
> view, just as
> among TLD holders you will find both views.

You are not typical of an SLD holder.

The community that has to be convinced here are the people who
operate corporate firewalls. If you do not have a firewall yet
you are not going to be interested in DNSSEC.

I speak to that communiuty on a regular basis. We actually operate
a lot of firewalls on an outsourced basis. 

That community does not want to have people walk their domain
for very good reason. Dealling with attacks costs real money.
Allowing domain enumeration will cost these people real money
as it will mean that systems will be attacked which the attacker
would not otherwise have discovered.

> When the "NO RR" was evaluated by the dnsext working group, 
> these opposing
> requirements were taken into account, and anti-enumeration 
> lost out.  

So did reality. 

Agenda denial is not a very credible tactic. Demand for DNSSEC
is negligible. Give me the names of ten supporters of DNSSEC in
its current form who are influential in the security community.

Not only is the community of potential DNSSEC users not represented
in this group, any time someone does drop by to make a request
they get met with hostility and patronizing remarks.

> If the WG made the wrong choice and if DNSSEC is 
> unimplementable because TLD
> holders fear enumeration and so SLD holders will have secure 
> path to the
> root zone, then it appears that there's really no choice 
> except to declare failure.  

Ah my way or the high way eh?

> > I would suggest there is perhaps a positive correlation 
> between on the
> > one hand to the IETF listening to to the requirements of those who
> > want to deploy a protocol on the one hand, and the protocol actually
> > getting deployed on the other.
> 
> Many voices were heard.  Primary among them were SLD holders, 
> who either
> don't care about enumeration, or who fear a two-decade approach to
> DNSSEC even more, or who fear spoofing even more.

The requirement denial approach seems to be the main reason
for delay. DNSSEC would have been deployed already if OPTIN
had been accepted.

> What *I* think, since you mentioned it, is that TLD holders who fear
> enumeration think that restricting AXFR is actually preventing

The enumeration issue is going to be a much bigger issue at
the SLD level. In fact that is what the NSA guy said in a 
DNSEXT meeting four years ago, for him enumeration is a real
issue.

The only reason this is taking so long is institutional. Over
a century of use has proved Roberts Rules of order to be a
much more effective way to run a meeting than the IETF has
devised. In OASIS we regularly complete specs much more 
complex than DNSSEC within two years.

I suggest that the solution to this problem is to submit
a new draft that describes an OPT-IN and OBFUSCATED NXT
record as 'experimental'. The spam and phishing groups do
not care a jot over spec level issues but they do care
about deployability, the enumeration issue and who is 
prepared to endorse the spec. It is also much more likely
that this application area will be a killer app for
DNSSEC than preventing spoofing. It has taken ten years
and a major spam crisis for people to realize that email 
spoofing was a sufficiently bad thing that something should
be done about it.

---

From: Peter Koch <[email-masked]>
Date: Sun, 23 May 2004 17:52:05 +0200

> would not otherwise have discovered.

this "ostrich approach" is the one reason why I'd really like to see NSEC in
its current form. Zone walking/AXFR has nothing to do with end system security
and "hiding" potential attack targets by AXFR blocks is dangerous at best.
What do these people do to make their IP adresses less guessable? Deploy IPv6?
This is not what the thread was started for and this kind of "security" will
distract from the real deployment issue here. The "registry type" zones are
special and it's them we need a solution for.

-Peter

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 13:15:00 -0700

Peter writes:
> this "ostrich approach" is the one reason why I'd really like 
> to see NSEC in its current form. 

Nobody has yet specified an attack that has anything like the 
effectiveness of zone walking. 

> Zone walking/AXFR has nothing to do with end system security

You argument amounts to 'security through plain sight' which 
is as discredited as security through obscurity. 

The application of design arguments such as security through
obscurity and end-to-end to operations is a bad mistake. It
is even worse to turn that argument into an ideology and
attempt to ridicule those who say the ideology is false.

Please do not attempt to claim superior expertise in this area
again.

> What do these people do to make their IP adresses less 

Deployment of NAT for this purpose is near universal. The IETF
tried to fight that for years as well. I am aware of the 
paper by Steve Bellovin on guessing IP addresses behind NAT,
as with your proposed dictionary attack it is orders of magnitude
harder and less reliable than direct observation.

> special and it's them we need a solution for.

Actually the same issue is true at the second level. Allowing
zone walking is not considered good security practice at any
level.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 13:38:14 -0700

> First, to mention something that is in no way Alex's fault, I 
> have to say
> that I find the use of the term "stakeholder" makes my teeth hurt.
> Different individuals have different interests, and lumping 
> them together
> such that "regulatory powers with guns", "captive customers", and
> "end users" are all in the same bucket just makes no sense to me.

How else can we address deployment other than by looking at the
people who might deploy but have refused to and asking them why
they did not?

I agree that it would be much better to address the fact that there 
are many stakeholders and that their interests may conflict. But
your argument seems to be that because there might be some
stakeholders that are not represented that they should all be ignored.

>  We also need to recognize
> that the DNS is used in many jurisdictions for many different 
> purposes.

The many jurisdicitions argument does not mean that we should ignore
all of them. In practice the type of legislation that has an 
effect on engineering work tends to be remarkably consistent
across jurisdictions.

> At this very late stage, taking in a last minute change to this set of
> specs both doesn't serve the long-unslaked thirst for deployment
> and would appear (note that verb, please) to privilege one set of
> interests after long discussion had come to other conclusions.

Nobody has yet stated an opposed interest here, there has been a
lot of 'protect the spec from change at all costs' and some
'lets force people to accept our security ideology' but no
real assertion of a valid opposition.

Having watched the previous discussions I did not see any real
debate over opposed interests then either. In fact all I have seen
for five years is the argument, 'we cannot fix the spec to make
it deployable, it will be deployed so very soon'.

> Put bluntly, we're at the "find technical errors stage", not 
> the design
> stage.  The behavior folks are trying to adjust is a known element of
> the design and has been for a long time.  It is not a technical error
> and a last minute attempt to adjust it doesn't make sense.

If this argument wins I predict that we will be debating the same 
exact argument in three years time.

I don't think the merits of this issue have ever been debated, 
I think we got fobbed off with the same agenda denial tactics
three and five years ago. Then we had some fillibustering to
make real sure that some people got their way even if the 
majority disagreed.

I suggest that the way forward here is for a small group to 
design an NXT that works, that we submit it as experimental 
and we let the market decide who is right.

The only reason the market is going to make a choice for 
experimental over an approved standard is if there is a 
genuine issue with the approved version.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 23 May 2004 21:59:44 +0100

> people who might deploy but have refused to and asking them why

To be fair I was talking about Nominet's stakeholders. And for various
reasons, mostly internal but given the issue was a surprise to certain
other ccTLDs too not entirely, we (Nominet) were perhaps less involved in
this process earlier on than we might have been - which we are now seeking
to correct: not by whinging from the sidelines, but by contributing.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 23 May 2004 21:55:20 +0100

--On 23 May 2004 21:25 +0100 Jim Reid <[email-masked]> wrote:

>     Alex> Just to illustrate the point, can you tell me what the
>     Alex> domain is in Nominet's zonefile right now, alphabetically
>     Alex> immediately following alex.org.uk. The 10 next ones? No, you
>     Alex> can't, without access to a secondary.
>
> Why do you think this information is of any value?

I am illustrating that Paul cannot enumerate the zone either accurately or
completely.

Or did you mean why is the zone as a whole of any value? Because people
(stakeholders) care about to what purpose ccTLDs data is put to, hence the
operators care for the same reason. For some but not all values of "care"
this is reflected in the law. I would suggest the facts (i) that many if
not every ccTLD operator has been the targets of attacks by various groups
attempting to extract data, and several have, with varying degrees of
success and at considerable expense, tried to sue such people, (ii) a
considerable of ICANN/GAC/ccTLD debate is spent on the intellectual
property of the zonefile suggests that the information is valuable to
someone.

> Why is it worth
> trying to conceal it, even though it's not that hard to find?

If it's not that hard to find, Paul would be able to answer my question.
Perhaps you can.

> More
> to the point, why do these stakeholders you keep banging on about?

See above. They do not want ccTLD operators publishing lists of domain
names registered, as they fear (accurately) those lists will be
misused. Just because there are other ways to get partial, inaccurate
lists of some of the domain names concerned, they do not see why the
ccTLD operator should be complicit in this. As I said before, just
because someone can break into your flat, it doesn't mean the landlord
should help them.

I believe the view has a good foundation in logic, but in the final
analysis it doesn't much matter to me if they believe the reason not to
have enumerable zonefiles is it increases the prevalence of bluebirds
flying over rainbows; at least in Nominet's case, the obligation is
to implement policy in the interests of, and in consultation with
stakeholders, which (to avoid people's teeth being put on edge) is
the old RFC1591 "in the interests of the local internet community". I am
not sufficiently paternalistic to tell them what is in their interests
and what is not.

Alex

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 23 May 2004 23:07:41 +0200

From my point of view (speaking as an individual), I am more worried 
    about the operational impact of a bunch of knuckle-heads who decided to 
    suck down COM via a NSEC chain walk.
(s/COM/a zone/)

That is my personal worry as well. I really don't want throw a lot
of resources to nameservers to accomodate script kiddies.

    On the other hand, it is hard to say if this activity will
    result in operational problems at all without a crystal ball.

We had a secured nl zone up for a year. This was published overhere.
When the zone came up, we noticed a lot of AXFR attempts. The only
zone walking activities noticed were our own attempts.

But of course, this doesn't mean that such thong won't happen when
it will be more common.

	jaap

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 May 2004 21:29:21 +0000

> ...  I really don't want throw a lot of resources to nameservers to
> accomodate script kiddies.

as if any of us had a choice about that any more.

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 24 May 2004 12:37:43 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> When the "NO RR" was evaluated by the dnsext working group, these opposing
> requirements were taken into account, and anti-enumeration lost out.  I had
> no dog in that race so this was only of academic interest to me -- "what 
> does BIND have to implement?" and "how can we get DNSSEC done in a decade?"
> where my only concerns.
> 
> If the WG made the wrong choice and if DNSSEC is unimplementable because TLD
> holders fear enumeration and so SLD holders will have secure path to the
> root zone, then it appears that there's really no choice except to declare
> failure.

Four years ago, when Simon's NO draft was considered by the WG, it
appeared entirely plausible that implementation-based rate limiting
mechanisms would be sufficent to offset any threat of elaboration.
With the subsequent increase of the
sophistication/size/duration/untraceablity/scope of such of distributed
abuse -- especially including zombie networks "for hire" -- we believe
this is no longer the case, and that protocol-level modifictions again
have to be considered by the WG as a possible "palliative" strategy.

The old anwer isn't the new answer, but I don't believe this the same
as declaring failure . . .

Regards

Geoff

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 24 May 2004 13:50:22 +0100 (BST)

FWIW I don't believe we've made clear the following point: Nominet is
prepared to commit our own resources to develop patch code to implement
draft-laurie-dnsext-nsec2 for, at a minimum, BIND 9.3, NSD 2.x and
Net::DNS::SEC.  The intent is to facilitate the evaluation of the
efficaciousness, environmental impact and interoperability of the use
of NSEC2 RRs.  We expect to make these patches available under the same
licenses as the corresponding source distributions, and to continue to
maintain and distribute the patches until either the draft expires
"with finality", or, perhaps, the patches or protocol become integrated
into the distributions themselves.

It's never been Nominet's intention to simply toss I-Ds over the fence
as a cynical exercise in FUD propagation, especially while the core
DNSSECbis docs are in WGLC.

Hope this helps . . .

Regards

Geoff

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 May 2004 14:16:17 +0000

> mechanisms would be sufficent to offset any threat of elaboration.

wow.  that was the wrong view, both on the facts and on principle.

> ... we believe this is no longer the case, and that protocol-level
> modifictions again have to be considered by the WG as a possible
> "palliative" strategy.
> 

you're using different words than declaring failure, but if adopted,
this position would have the same result as declaring failure.  

nothing we can do in dns will ever prevent useful enumerations by bad 
people who will use the data to index your whois and spam your customers.

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 24 May 2004 17:46:32 +0100 (BST)

> wow.  that was the wrong view, both on the facts and on principle.

Perhaps, but, FWIW, that was the message being delivered by several
participants in the DNSSEC "educational outreach" process at the time . . .

Regards

Geoff

---

From: [email-masked]
Date: Sun, 23 May 2004 14:56:45 +0000

> This shows why DNSEXT should transfer work on DNSSEC to the security

	Again?  The last time the security area had DNSSEC, we 
	got stuff that could not be deployed due to excessive
	"chatter" btwwn parent and child.  There are more good	
	security people on the DNS lists than DNS people of any sort
	on the security lists.  

> requirements of the security community.

	Philip, why do you presume that the "security" community speaks
	with a single voice? 

> Phill

--bill

---

From: [email-masked] (Ted Lindgreen)
Date: Mon, 31 May 2004 14:58:19 +0200

[Quoting Olaf Kolkman, on May 20, 22:42, in "Re: Proposal to fix  ..."]
> Dear Colleagues,
....
> June 1 I'll reject this as a work item.
> 

After following the discussion with great interest, I think that:

1. The virtues of making NSEC-walking difficult seem to be largely
   overestimated by some people. For all devious purposes (spamlist
   building, whois lurking, etc), there are already numerous ways
   to build a close enough list of domainnames with or without NSEC.
   I really think that the problems at hand will hardly be
   influenced by having NSEC or NSEC2 in practice.

2. The time, the work, and the funding needed to redo DNSSEC once
   again seems largely underestimated. Having been involved in the
   work to go from 2535 to the current docset, I don't believe
   anyone who says that we can stamp out a DNSSECter docset before
   2006 or perhaps even 2007.
   As for funding such work, I will have a large problem to defend
   further funding for NLnet Labs on DNSSEC if we go back to the
   basic design. NLnet Labs must then most likely drop their work
   on DNSSEC on the floor.

So, I think that the working group should NOT delay DNSSECbis by
trying to fold in NSEC2 this late in the process. If NSEC2 needs
to be worked out it should be done in a separate track.

Regards,
-- ted

---

From: Greg Hudson <[email-masked]>
Date: Mon, 31 May 2004 11:00:12 -0400

(I agree with Ted.)

On Mon, 2004-05-31 at 10:29, Geoffrey Sisson wrote:
> Please note that information leakage is not the only issue attributable
> to NSEC RR elaboration: resource depletion due to possibly frequent,
> multiple simultaneous chains of elaboration could also be significant.

Two answers:

(1) The normal load on most of these servers is pretty high.  An awful
lot of spammers would have to be doing simultaneous nsec walks (which
are rate-limited to some extent by needing to wait an RTT for each
request) before it would become a noticeable factor.

(2) An nsec walk is an awful lot more efficient than a PTR walk.