Subject: Re: Proposal to fix NSEC

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

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

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]

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

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

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: 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: [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