Subject: RE: Proposal to fix NSEC

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

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

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.

--
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: Robert Elz <[email-masked]>
Date: Sat, 22 May 2004 13:53:05 +0700

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

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

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.

If they were to publish it, they could get copyright protection, but as
they don't want that, they're resorting to all kinds of avenues to try
to keep the secret - which is, without doubt, difficult, or impossible.

kre

---

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:

> 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: Roy Badami <[email-masked]>
Date: Sat, 22 May 2004 10:03:56 +0100

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> Roy is stating that this issue is a showstopper for
    Hallam-Baker,> him. 

For the record, all I actually said that was that ccTLDs have raised
some concerns, and I disgreed with some of the sweeping arguments that
were being used against such possible concerns...

Though it appears now that Nominet have pretty much stated that this
is a showstopper for them...

   -roy

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 15:07:16 +0000

> Paul,

I'm Paul.  He's Robert.

> > ...
> ...
> might be true of VRSN. Current RFCs permit non-publication. ...

Have any of you here looked at <http://www.isc.org/ops/ds/>, perchance?

The thing that's boggling my mind at the moment is that the stakeholders,
or ccTLD operators, or VRSN, believes that by prohibiting zone transfers
they are preventing enumeration.  It just ain't so, and while I'm still
Paul and he's still Robert and I can't authoritatively speak for him, I
suspect that Robert's use of the word "absurd" has to do with the general
misconception that preventing direct enumeration at the DNS protocol level
is actually buying anything for anybody.

> ... Whether or not all these people are unduly worried is to an extent
> a moot question, ...

No, it's not moot, not yet anyway.  DNSSECbis as documented in the current
set of drafts and as implemented in BIND 9.3.0-beta4 has undergone
significant review and lab testing and appears ready for deployment.  If
the DNS protocol development community is going to back away and redesign
it again, then two questions have to be answered first:

   1. what exactly is it that you think you're going to get by making
      the enumeration of your zones an indirect activity rather than
      a direct one, noting that anyone who wants the enumeration can
      get it by indirect data mining techniques...?

   2. why are we doing this in May, when every other time that we've
      pulled DNSSEC back for yet another redesign that's added one or
      two years to the schedule, we've done it in December...?

> ... 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.  Take a look at <http://www.isc.org/ops/ds/> before
you try to decide what's "finally and actually" revealed, no matter what.
(Noting that the ISC Domain Survey does not use or depend upon AXFR.)

---

From: [email-masked]
Date: Sat, 22 May 2004 17:26:53 +0200

> is actually buying anything for anybody.

With some knowledge of how the .no domain operates, I think it is fair
to say:

At least some stakeholders are fully aware of the fact that prohibiting
zone transfers does not prevent enumeration. However, they still find
it valuable to prevent zone transfers - the important point here being
the amount of work (and time) it takes to perform the enumeration: If a
domain can be enumerated in a month today, and could be enumerated in a
minute with NSEC (just to take an example), this is a dramatic reduction
in the amount of work needed - and a correspondingly lower barrier to
at least some undesirable uses of the domain data.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Alex Bligh <[email-masked]>
Date: Sat, 22 May 2004 16:38:36 +0100

Paul,

> I'm Paul.  He's Robert.

Apologies

> Have any of you here looked at <http://www.isc.org/ops/ds/>, perchance?

Yes - it works by PTR query. That does not give a complete and
accurate enumeration, nor does it give a single snapshot in time.
Nor does is it published BY the ccTLD operator. That is like saying
there is no point in protecting my streetmap of SF because you and
everyone else have a streetmap of SF that's "quite like it". For the
sake of completeness awk ... | fgrep co.uk | uniq on AOL's mailserver
logs is also going to produce another similar but inaccurate database.

Just to illustrate the point, can you tell me what the domain is in
Nominet's zonefile right now, alphabetically immediately following
alex.org.uk. The 10 next ones? No, you can't, without access to a secondary.

> they are preventing enumeration.

They are preventing enumeration (i.e. provision of a 100% accurate
copy by the ccTLD publishing the information). They are not preventing
you or anyone else from compiling their own, incomplete and inaccurate
work from information not derived from the ccTLD operator.

> If he said that, he was wrong.  More likely you misunderstood him.

I am not sure which part of the following I am meant to have misunderstood
before I agreed with it:

--On 21 May 2004 20:31 -0700 "Hallam-Baker, Phillip" <[email-masked]> 
wrote:
> 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.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sat, 22 May 2004 16:53:57 +0100

--On 22 May 2004 15:07 +0000 Paul Vixie <[email-masked]> wrote:

> No, it's not moot, not yet anyway

It is perhaps an interest reflection on the workings of the IETF that the
requirements of those deploying the protocol (ignoring, for a minute, why
they have those requirements) appear occasionally to be only a secondary
consideration in protocol design. 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. In the context of
a requirement to preserve existing functionlity, the fact that *you* think
requirements are misplaced (I don't, but who knows, in the final analysis
you might well be right) doesn't cut much mustard when the requirement
comes from the internet community, as communicated to those who are going
to make the deployment decision.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 16:34:39 +0000

> consideration in protocol design.

I apologize for the apparent truth of that reflection, but it's inaccurate.

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.

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.  Perhaps Ohta or Bernstein would like to take a shot at the problem.

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

> In the context of a requirement to preserve existing functionlity, the
> fact that *you* think requirements are misplaced (I don't, but who
> knows, in the final analysis you might well be right) doesn't cut much
> mustard when the requirement comes from the internet community, as
> communicated to those who are going to make the deployment decision.

What *I* think, since you mentioned it, is that TLD holders who fear
enumeration think that restricting AXFR is actually preventing
enumeration, and that if they'd spend a few years in the trenches
against spammers and data miners they would come to the conclusion that
"all useful malevolent forms of enumeration are already possible and are
already being done" and would then conclude that a one-decade DNSSEC is
better than a two-decade DNSSEC, given that all other things are equal.

---

From: David Blacka <[email-masked]>
Date: Sat, 22 May 2004 16:47:11 -0400

> is actually buying anything for anybody.

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.

 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 because either a) they don't know 
they can just ftp the zone, b) they are too lazy to go through the 
moderate hoops in order to do so, or c) the want to use the information 
for something bad.

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

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 May 2004 13:54:00 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

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

But the EU directive in question applies in both jurisdictions. And
anyway the answer a lawyer gives can depend on the question asked.

    Alex> For me the point, however, isn't wholly about the law. It's
    Alex> about what stakeholders want.

Even when they're misguided? Or if they want the impossible?

Note too that this DNS stakeholder wants his zones secured from
spoofing. And he wants that now. Though perhaps that's also a
misguided demand for the impossible. :-)

    Alex> Current RFCs permit non-publication. 

No they don't, though I suspect this depends on your definition of
"publication". No DNS RFC says anything about access controls. Apart
from saying servers can sometimes return REFUSED -- which may or may
not be for reasons to do with access controls -- the RFCs are silent
on this matter. So the current RFCs neither prohibit or allow
non-publication, for your definition of this term. In purely DNS
terms, entering names into a public zone file constitutes
publication. If something isn't to be published, it shouldn't go in
the DNS.

    Alex> The current DNSsec proposal prohibits this. 

Wrong again. The current drafts just make it more explicit that
attempts to conceal a zone's contents by restricting zone transfers --
ie security through obscurity -- are futile. This should not come as a
surprise to anyone. As has already been pointed out, there are many
techniques that are currently in use to enumerate a zone. It seems
some of us haven't yet got over that. Sigh.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 23 May 2004 19:05:12 +0100

Jim,

> anyway the answer a lawyer gives can depend on the question asked.

As I am sure you know, EU directives (as opposed to regulations and treaty
articles) are implemented by national law, and the implementation can vary.
Further, they are implemented in the context of existing national law,
which varies. But heh, let's not make this alt.lawyers.barrackroom.

> Even when they're misguided? Or if they want the impossible?

It isn't impossible. We have supplied an example demonstrating making
zonefiles not enumerable via DNSSEC. Noone yet has suggested NSEC2 is
fatally flawed. The consequent effects on delay of implementation may be
undesirable, but that is a different point. Nor, in my view, is
it misguided.

Note people are not asking that it ccTLDs should make it impossible
to discover the contents of their zones to any extent. They are simply
asking that ccTLDs should not themselves publish them in toto.

> on this matter.

They permit a refused answer. They do not specify how that can be
generated. Where RFCs permit behavior (refused) and do not constain
when that behavior may or may not be used, it is up to local policy.
And, indeed, that administrative (policy) refusal appears to be
utilized by every DNS server codebase in non-minimal deployment,
many of whom claim RFC compatibility.

> attempts to conceal a zone's contents by restricting zone transfers --

All it seems to me they say is that NSEC is mandatory, and zone enumeration
is a consequence of NSEC.

> ie security through obscurity -- are futile.

Your view is that it is futile. That view appears not to be shared by
everyone. I would suggest it is not shared by those who bother to lock down
AFXR either. I am surprised if you wouldn't go so far as to allow that
it was a matter of opinion.

And in the end, the view that matters is the view of those who want to
deploy it (and, in registry cases, their stakeholders). Otherwise you will
have designed a protocol which is perceived as flawed, and no matter how
much you say that the perception is wrong (whether you are right or wrong),
it's deployment will be significantly hindered. I can tell you that the
interest in zonefile enumeration and spam, exceeds interest in DNSSEC
deployment by a couple of orders of magnitude in terms of the people I talk
to. Many see the security issues in DNS fixed by the little padlock that
appears on their web browser. Many of the more enlightened ones see DNSSEC
as an undeployable nightmare. Please bear in mind I am making the foregoing
statements as a DNSSEC supporter, and in the context of an organization for
whom deployment of DNSSEC is a key strategic aim. The point is that if you
want better stakeholder acceptance, and hence greater deployment, listening
to people's concerns is important.

To me it seems a fair view of the argument goes like this:

1. Current DNSSEC permits enumerability. Previous DNS did not prohibit
   disallowing enumerability through AXFR, and as such that became a
   feature in all significant nameserver deployments, that has been
   utilized by many people.

2. Some people view preventing enumerability as important from a
   local policy point of view. Amongst those are ccTLD operators who
   are concerned for reasons of data protection, copyright, spam and
   local internet community driven policy. Also amongst those are
   certain members of the security community who fear leakage of
   information.

3. A further number of people believe the policy of those in (2) to
   be futile, for various non-DNSSEC related reasons.

4. Fixing the concerns in (2), via NSEC2 or otherwise, can only delay
   DNSSEC being ready for deployment. Everyone wants DNSSEC to be
   deployable quickly. It is possible there is a fix or workaround
   less likely to delay than NSEC2, but if there is, it hasn't been
   published here.

5. Fixing (2) is likely increase the speed and scope of deployment
   once the protocol is ready for deployment, on the basis those holding
   view (2) above are less likely to deploy, and less likely to deploy
   quickly, if their concerns are not addressed. Further, fixing (2)
   after significant deployment is likely to be problematic.

I believe (3) is a red-herring for this group: it seems to me a local
policy issue, and however ill-advised you might feel people to be to take
that policy, the case is at least arguable and new revisions of protocols
should not break existing functionality.

What I believe we are talking about is a simple trade-off between (2) and
(5) on the one hand, and (4) on the other.

Alex

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 May 2004 19:27:50 -0000

Jim Reid writes:
> The current drafts just make it more explicit that

I have two TXT records for names of the form k.cr.yp.to, where k is a
hex MD5 hash of some cryptographic data. One of them is

   '762fa7ce541bf0817b4f913a2b51a5cd.cr.yp.to:0d32ae8d1ef36e9c71fef18c9a603299

in tinydns format. Please tell us the other one.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Ted Hardie <[email-masked]>
Date: Sun, 23 May 2004 12:46:13 -0700

At 7:05 PM +0100 05/23/2004, Alex Bligh wrote:
>to.

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.
Not all that salient, really, so forgive the digression.

Second, we're here to make engineering decisions.  We're not trying
to make those in ignorance of regulatory realities or operational
desires, but we have to recognize that it only makes sense for
us to discuss them here in terms of the engineering effects (we're
not going to change regulations in any jurisdiction, get people to
be "more interested" in one thing than another, or otherwise change
the political or economic landscape).  We also need to recognize
that the DNS is used in many jurisdictions for many different purposes.
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.

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.

Speaking personally, and with regards for all concerned,
						Ted Hardie

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 May 2004 21:25:48 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

    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? Why is it worth
trying to conceal it, even though it's not that hard to find? More
to the point, why do these stakeholders you keep banging on about?

---

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:

> 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

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: Paul Vixie <[email-masked]>
Date: Sun, 23 May 2004 21:28:02 +0000

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

i never said i could.  what i said was that i could get a complete useful
enumeration, containing everything a spammer or marketroid would need in
order to make "the bad use" of whois that ccTLD's supposedly don't want
made.

---

From: [email-masked]
Date: Sun, 23 May 2004 05:41:11 +0000

> to make the deployment decision.

	Hum... one might argue that the folks who have been putting
	up money for development and have indicated why they want certain
	features in DNSSEC are prepared to deploy based on the current
	material.  If there are folks whos requirements for features differ
	from the currently funded activities, then they are free to back
	their requirements with monies to cover development and integration
	costs. Its not like this is the end-all for DNSSEC. One should 
	retain the perspective that this is the -third- iteration of the
	spec, with associated code and attempts at deployment.  There
	is no reason to beleive that further, iterative refinement would
	not be forthcoming.  Lets just get this stuff out the door and then 
	look at what should be in DNSSECv5.

--bill