Subject: Re: Proposal to fix NSEC

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
>
>
>>> NSEC provides an index to whois.
>> ...
>> However, "fixing NSEC" will not fix the real (whois) problem.
>>
>> -- teds
>
> 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: 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

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 22 May 2004 06:55:05 -0700

> Don't be totally absurd.    As Jaap already showed (after 
> more research
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 22 May 2004 08:09:15 -0700

> > 
> > 	Here you just make the problem harder by an equal factor for
> > 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.

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 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 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
> and "hiding" potential attack targets by AXFR blocks is 
> dangerous at best.

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 
> guessable? Deploy IPv6?

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.

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

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

---

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: [email-masked] (Geoffrey Sisson)
Date: Mon, 24 May 2004 17:46:32 +0100 (BST)

Paul Vixie <[email-masked]> writes:

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