Re: dictionary attack on nameservers
bman...@vacation.karoshi.com
> the zone, the more hits you get, the more accurate your "AXFR" will
> be). So my question right now is:
>
> Why is so much effort pumped in to a new NSEC solution for DNSSEC when
> people can walk DNS zones so easily right now?
GACK!!! would you stop telling people how some of
us enumerate thier zones when AXFR is blocked and
they don't make the zone contents available in other
ways (ftp for example). :)
--bill
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Samuel Weiler
> 229360 words in 46 minutes, 4986 words/minute.
>
> This yieled 44886 domain names. Which is a succes rate of 19.57%
> (estimate) (of the 229360 words)
>
> (there are lies and there is statistics, but 20% of 4986 is about
> 1000. So you get about 1000 valid domains/minute by doing this).
>
>
> NL has 1 million domain names, so this gives me only about 5 percent
> of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
> 15 hours), I should get almost the whole NL zone.
This logic is bogus. The density of hits with dictionary words is
probably greater than the density of hits with other namespaces (like
pairs of words). While 240K names yielded 45K hits, you'll have to
try far more than 5M names to hit all 1M names in the zone.
For example, if you test the set of all dictionary names with 123
concatenated onto them, (ie. mortgage123.nl), you'll test the same
number of names as you did in your experiment so far, but get far, far
fewer hits. Even so, some of those names exist in the zone, and
absent some a priori method of predicting which ones do, you have to
test them all to find which ones do.
-- Sam
Christian Huitema
> mind they can only get 90%. And btw, you really have a hard time
> blocking this... ]
There are many other ways to achieve this result. You could also bang
your dutch dictionary words one by one against a bunch of search
engines, and parse the pages for HTTP URL that belong to the .NL domain.
You will very quickly get several thousand names, including the likes of
"example123.nl"...
-- Christian Huitema
Paul Vixie
> ..., I should get almost the whole NL zone. I haven't look into this
> but 80%, maybe 90% sure looks feasible. And the better the dictionary,
> the better the results of course. Also the attack is highly parallel,
> 2 computers querying 2 different nameserves, would cut this time in
> half.
actually, if you have bind8 or bind9 and if your operating system has
kernel-visible pthreads, you can parallelize using the "irs" interface.
see "bind8/contrib/manyhosts/" for an example of how altavista used to
postprocess its web logs back in the days before google. (so, you don't
actually need two computers to parallelize this function.)
> So within a day you can get an AXFR of any zone out there (the bigger
> the zone, the more hits you get, the more accurate your "AXFR" will
> be). So my question right now is:
>
> Why is so much effort pumped in to a new NSEC solution for DNSSEC when
> people can walk DNS zones so easily right now?
all i can say is, humans are involved, and humans love complexity, and
humans hate to be told that they're solving the wrong problem. let's
have a look at the ol' archives, shall we?
From: Paul Vixie <pa...@vix.com>
To: namedr...@ops.ietf.org
Subject: Re: Proposal to fix NSEC
Date: Sat, 22 May 2004 16:34:39 +0000
...
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.
or, even more succinct:
From: Paul Vixie <pa...@vix.com>
To: namedr...@ops.ietf.org
Subject: Re: Proposal to fix NSEC
Date: Sun, 23 May 2004 21:28:02 +0000
> I am illustrating that Paul cannot enumerate the zone either
> accurately or completely.
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.
yet, interest in NSEC2 (and now NSEC3) persists. thank you for proving
that useful enumeration does not depend on AXFR or NSEC, but i think that
the proponents of NSEC2 (and now NSEC3) believed my assertions on this
point and will not be swayed by your evidence. they do not doubt that
"all useful enumerations are already possible", but they live in a world
where they have to be seen "doing something about the problem". because
of the way IETF works, that probably means "we all have to be seen doing
something about the problem" even though, as first stated, and now proven,
there either is no problem, or the problem doesn't come from NSEC.
> Btw, I will be happy to try this out on other TLD's out there :-)
i suggest that you do them all. it won't change anything -- we'll still
rush headlong into another decade of incremental complexity in dnssec --
but it will be satisfying to have the true purpose of that complexity
exposed in advance, for all to see.
note-- ISC will begin work on NSEC3 as soon as there's funding/interest
in it. the views expressed here are personal, and do not reflect isc's
commitment to implement whatever the community decides upon.
paul
Roy Arends
> The main point of my post is that I can enumerate (for +/- 90%) a zone
> in 24 hours, even if AXFR is blocked.
>
> [ The people interested in this kind of information certainly don't
> mind they can only get 90%. And btw, you really have a hard time
> blocking this... ]
>
> So do we want nsec2/3/X to close down the remaining 10% or do we say:
> we can live with enumeration in DNSSEC because even in the DNS people
> can walk our zone?
I have seen no claims that NSEC2/3/X can prevent zone walking or
enumeration. The goal is to make zone walking more expensive.
The lock on my front door does not prevent break-ins. Its goal is to make
break-ins more expensive.
Roy
Ted Lindgreen
> I have seen no claims that NSEC2/3/X can prevent zone walking or
> enumeration. The goal is to make zone walking more expensive.
>
> The lock on my front door does not prevent break-ins. Its goal is to make
> break-ins more expensive.
When talking "more expensive", it is relevant to weight:
1. how much more expensive
2. the cost of the lock
3. the value of what is being protected
ad 1. It has being shown (several times) that (90-99%) zone
enumeration without AXFR is simple and dirt cheap.
Most of us know that both spammers and domainname-traders
are doing this already for years on a daily basis with
all TLDs that have blocked AXFR.
ad 2. The cost of the proposed lock (NSEC2/3/X) means a new
protocol change, which is rather expensive.
ad 3. We are talking about the protection of one little aspect
(100 against 99% enumeration) of otherwise public
information. It has also been argued ((several times) that
for most, if not all, evil usage of zone-enumeration 90+ %
enumeration suffices.
To me it seems that in this case the weighting is completely out
of balance.
Regards,
-- ted
Ted Lindgreen
> "The people" have different reasons, some of them want a 100% copy and some
> of them want near-realtime "diffs". And it's always the last 10% that makes
> 90% of the price ...
I am probably naive, so please enlighten me: for what "people" would
this last few percents (which probably consists mainly of short-lived
bogus domains like spammer1234.tld) be of such high interest?
Certainly not for the spammer, domainname-grabber, data-miner, etc
type of "people"?
Jay Daley
Ted wrote on 29/07/2004 09:06:24:
> ad 1. It has being shown (several times) that (90-99%) zone
> enumeration without AXFR is simple and dirt cheap.
I'm sorry to be picky but I don't think the above is true.
When people register a name they use a name from a pool of possible names.
As a zone grows in size people begin to exhaust the easy pools and so
need to invent new pools. So the initial pools are often
very short names (2, 3, 4 characters)
generic words (eg music, buses, teeth)
organisation/personal names
but as these grow people start to invent new ones
generic hyphen generic
generic plus number
and so on.
So the smaller a zone is, the easier it is to enumerate. For small zones
I can well believe a high percentage is possible. However as zones grow
the problem can get significantly harder.
If someone really has done this against a large zone then please let us
know. If you want to test it against ours then please let me know so that
we can prepare for it.
Jay
Olaf M. Kolkman
>So do we want nsec2/3/X to close down the remaining 10% or do we say:
>we can live with enumeration in DNSSEC because even in the DNS people
>can walk our zone?
>
>
That is exactly what I think we should do first. Get the requirements
on which this comunity wants to base its developments and then make the
tradeoffs.
See
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html
--Olaf
Roy Arends
> >So do we want nsec2/3/X to close down the remaining 10% or do we say:
> >we can live with enumeration in DNSSEC because even in the DNS people
> >can walk our zone?
> >
> >
>
> That is exactly what I think we should do first. Get the requirements
> on which this comunity wants to base its developments and then make the
> tradeoffs.
>
> See
> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html
The important thing is to get consensus within the WG on a few points.
Most importantly:
o Will current deployment plans for dnssec-bis be hurdled with nsec++.
o Will deployment be feasible with dnssec-bis for _large_ tlds.
If either one is a yes, lets drop nsec+.
Roy
Geoffrey Sisson
> Why is so much effort pumped in to a new NSEC solution for DNSSEC when
> people can walk DNS zones so easily right now?
I can't speak for everyone, but we (Nominet) are advised that we have
a responsibility to protect the confidentiality of data in the .uk zones,
even if this cannot be done perfectly.
Also, I use to think that, even if "NSEC+" were available, that NSEC
was sufficient for {in-addr,ipv6,e164}.arpa. Now I'm not so sure.
While any one zone in these hierarchies is trivially enumerable w/o
NSEC, the elaboration of the aggregate trees is a bigger problem which
is considerably reduced by NSEC. (Okay, maybe not so hard to elaborate
e164.arpa yet by any means . . .) The reverse trees and enum may prove
to be killer apps for NSEC+.
Peter Koch <p...@TechFak.Uni-Bielefeld.DE>
> the last 10% that makes 90% of the price ...
I think this is also a good summation.
Regards
Geoff
Roy Arends
> [Quoting Roy Arends, on Jul 29, 9:10, in "Re: dictionary attac ..."]
>
> > I have seen no claims that NSEC2/3/X can prevent zone walking or
> > enumeration. The goal is to make zone walking more expensive.
> >
> > The lock on my front door does not prevent break-ins. Its goal is to make
> > break-ins more expensive.
>
> When talking "more expensive", it is relevant to weight:
I did not say that the goals justify the means, nolo contendere on the
validity of the details you have provided.
Roy
Ted Lindgreen
> If someone really has done this against a large zone then please let us
> know. If you want to test it against ours then please let me know so that
> we can prepare for it.
I am not sure what you call "a large zone", so also not if .nl
qualifies (it is in the top-5 or so of largest zones, but, of
course, much smaller than .com).
The .nl domain has some 1.3M delegations, some 30k domains are
newly registered and some 5k are released per month (from data
over the first few months of 2004).
I know of a number of registrars who keep daily updated, and
very accurate lists of registrered and returned domain names.
For .nl and also for other TLDs.
These guys use various techniques to keep their lists accurate
and up-to-date. Although highly effective, these techniques are
neither complicated, nor costly for the registrar.
However, their load the .nl nameservers is significant, and thus
one can easily see and determime who/what is causing it in the
nameserver-traces which we routinely investigate in our testlab.
As for your second question: I do not think that any preparation
by your side is needed for us to "attack" your TLD, as the load
of our "attack" on the .nl zone was not even noticed (but will,
of course, be clearly visible in the nameserver-traces).
Regards,
-- ted
Geoffrey Sisson
> When talking "more expensive", it is relevant to weight:
>
> 1. how much more expensive
> 2. the cost of the lock
> 3. the value of what is being protected
>
> ad 1. It has being shown (several times) that (90-99%) zone
> enumeration without AXFR is simple and dirt cheap.
> Most of us know that both spammers and domainname-traders
> are doing this already for years on a daily basis with
> all TLDs that have blocked AXFR.
>
> ad 2. The cost of the proposed lock (NSEC2/3/X) means a new
> protocol change, which is rather expensive.
>
> ad 3. We are talking about the protection of one little aspect
> (100 against 99% enumeration) of otherwise public
> information. It has also been argued ((several times) that
> for most, if not all, evil usage of zone-enumeration 90+ %
> enumeration suffices.
>
> To me it seems that in this case the weighting is completely out
> of balance.
There's a time consideration which this analysis doesn't take into
account: If `perfect' snapshots (less negligible effects due to routine
IXFRs) of the owner names in zones can be obtained frequently and with
low latency, then new possibilites become available.
It's one thing to have a photo; another to have a film.
Regards
Geoff
Ted Lindgreen
> There's a time consideration which this analysis doesn't take into
> account: If `perfect' snapshots (less negligible effects due to routine
> IXFRs) of the owner names in zones can be obtained frequently and with
> low latency, then new possibilites become available.
>
> It's one thing to have a photo; another to have a film.
I am affraid I have lost it now, please enlighten me:
1. the argument against enumeration is the European (and/or
other) privacy legislation;
2. it is clear that 99% enumeration on a daily basis is currently
practice (perhaps not desirable, but real practice);
3. NSEC may provide for 100% correct snapshots, valid in the
interval between zone-updates.
Do I correctly understand that you are saying that 2 is "a photo"
and 3 is "a film"?
And with that, must I understand the privacy-lawyer's opinion that
for information, which is in the DNS for deliberate publication,
"filmshots at zone-update intervals" are unacceptable, while
"daily photo's" are current practice?
I am affraid I have really lost it...
-- ted
Jay Daley
Ted wrote on 29/07/2004 10:28:08:
> I am not sure what you call "a large zone", so also not if .nl
> qualifies (it is in the top-5 or so of largest zones, but, of
> course, much smaller than .com).
> The .nl domain has some 1.3M delegations, some 30k domains are
> newly registered and some 5k are released per month (from data
> over the first few months of 2004).
That will do.
>
> I know of a number of registrars who keep daily updated, and
> very accurate lists of registrered and returned domain names.
> For .nl and also for other TLDs.
>
> These guys use various techniques to keep their lists accurate
> and up-to-date. Although highly effective, these techniques are
> neither complicated, nor costly for the registrar.
> However, their load the .nl nameservers is significant, and thus
> one can easily see and determime who/what is causing it in the
> nameserver-traces which we routinely investigate in our testlab.
With respect this is still anecdotal. Where is the real data? i.e. "By
dictionary attack X managed to guess Y% of the 1.3m names".
Jay
Ted Lindgreen
> > I know of a number of registrars who keep daily updated, and
> > very accurate lists of registrered and returned domain names.
> > For .nl and also for other TLDs.
> >
> > These guys use various techniques to keep their lists accurate
> > and up-to-date. Although highly effective, these techniques are
> > neither complicated, nor costly for the registrar.
> > However, their load the .nl nameservers is significant, and thus
> > one can easily see and determime who/what is causing it in the
> > nameserver-traces which we routinely investigate in our testlab.
>
> With respect this is still anecdotal. Where is the real data? i.e. "By
> dictionary attack X managed to guess Y% of the 1.3m names".
Dear Jay,
Thank you for calling our work "anecdotal".
You dispute the existance of cybersquatters, spammers, etc. using
fairly accurate lists of existing domainnames. You even dispute
the possibility of those techniques, and want us to come up with a
full quantitative analysis of one such technique.
However, NLnet Labs is not founded (nor funded) to prove the obvious,
and therefore we will not waste more time this than we have done
already.
For us it suffices, that:
1. with very little work we could do a dictionary attack on .nl,
revieling the number of domainnames we expected (feared);
2. from work with/at the .nl registry and registrars we know that
a number of registrars maintain accurate and uptodate lists of
many TLDs, despite that most of these TLDs have closed AXFR
many years ago;
3. from work in our testlab with traces of .nl nameservers we have
seen how some of those registrars obtain part of the info in 2;
4. from other postings in this thread it is clear that others have
seen various other methods to obtain good lists of registered
domainnames in the current DNS even when AXFR is blocked.
If you can prove, or at least provide reasonable evidence, that in
a world where above already takes place, NSEC2/3/X versus NSEC makes
enough of a difference to necessitate a redo of the protocol, please
do so.
Sofar, I've only heard about "some privacy-laywer's opinion", vague
"new possibilities" that perfect against 99% accuraty could allow for
(ghost-hunting), and thirdly, fear that nameservers could suffer
overload from NSEC walking (which is provably incorrect: the current
attack-techniques impose already a much greater load, plus that just
making the zone file available via ftp is even more effective).
Please explain to us why NSEC2/3/X is REALLY needed, instead of
asking us to prove the obvious.
-- ted
Ted Lindgreen
> The reasons for the requirement for non-traversal of zones (NSEC2/NSEC3)
> have been expounded at great length; I don't see any purpose in repeating
> them again. As far as I can tell, the w/g reached consensus that there was
> a requirement (perhaps not one you have) but that it would not form part of
> DNSSECbis.
I'm affraid you are misinformed: the w/g has NOT yet reached consensus
on this a requirement.
Discussing and, if necessary, then formulating such a requirement
is a task the w/g still has to do. The (rough) consensus that was
reached, and perhaps confused you, was that the w/g would discuss
this topic at some later time, and not as part of the DNSSECbis
document set.
Edward Lewis
attacks, "privacy," and the motivation for and threat of DNS data
mining is not getting us very far.
Thanks to Miek for taking a stab at enumerating the effort to
dictionary-attack a zone. But to really make it convincing, I'd like
to see an attack carried out and compare the results to the real
zone. Only when we hit a high percentage of the names (65%, 80%,
90%) would I be really interested in the measure of resources needed
to pull it off.
But I stress that it's a bit of red herring (non-topic).
As far as the issue of zone enumeration, my thoughts fall into this:
1) When DNSSEC originated, zone enumeration was not a threat.
Because of this, I think DNSSECbis, meeting other goals, is done and
ready to be published as a doc set. If operators aren't happy with
it, they can treat the doc set the same way they treated RFC 2065 and
RFC 2535.
2) I do think zone enumeration is a nuisance. I wouldn't rate it a
threat to DNS, nor would I rate it a desired feature. I applaud
anyone's initiative to study the issue and propose a means to
accomplish all of what DNS and DNSSEC stands for while preventing
zone enumeration.
I don't blame all network malfeasance (e.g., spam) on zone
enumeration though. Zone enumeration just one element. But still,
the DNS ought to limit it's network slag. (Slag is a waste product
in steel production. Olafur reminds me now and then that I need to
avoid obscure words...;))
3) Zone enumeration is not a privacy issue. Data in the DNS is not
private, but bulk access to it can be a problem. The situation is
like a company on-line phone list. I can ask for the number of one
person, but not the organizational structure of the company. Don't
think of that as a privacy concern though - thing of it as an abuse
of the service.
DNS is lookup, not search. DNS ought not ever encourage a "search"
of it's data store. Not because of privacy, but because we don't
want mission creep.
4) The way I see NSEC is that we started out with the goal of
pre-computed, fairly-fine-grained authenticated denial statements.
We accomplished this in a manner that made zone enumeration possible.
It would have been nice to not make zone enumeration possible, but it
is a by product. (Much like autos do not want to emit carbon
monoxide - but in order to achieve transportation within the other
restrictions, it happens.)
5) The way I see "improvements" to NSEC in this manner is like a
second generation engineering effort. (Like electric cars.) It
would have been real nice to not need to remove zone enumeration -
either be declaring it a non-issue or by not having engendered it in
the first place.
IMHO - we ought not fight the efforts to find a better version of
NSEC. But, at the same time, the effort to find a better NSEC ought
not stand in the way of getting DNSSECbis fielded.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
"I can't go to Miami. I'm expecting calls from telemarketers." -
Grandpa Simpson.
Roy Arends
> Roy Arends wrote:
>
> > I have seen no claims that NSEC2/3/X can prevent zone walking or
> > enumeration. The goal is to make zone walking more expensive.
> >
> > The lock on my front door does not prevent break-ins. Its goal is to make
> > break-ins more expensive.
>
> This is a false analogy: the people who want to enumerate DNS zones
> wouldn't be spending their own money - they have zombies and botnets to
> do the work for them.
I was referring to expensive as cost in general (i.e. time, effort, etc)
not just valuta. I did not specify if investment were direct, or by
proxy.
The general approach for defense against attack vectors is to increase
their cost. Making attack vectors impossible is Deity.
Roy
Greg Hudson
> > ad 1. It has being shown (several times) that (90-99%) zone
> > enumeration without AXFR is simple and dirt cheap.
>
Your subsequent analysis only addresses dictionary attacks. But other
attacks have been mentioned here (web-crawling, PTR walking), although
we don't really have numbers on how effective any of the attacks are.
(As many people have pointed out, "a dictionary attack got me 5% in a
short amount of time" doesn't really prove or even suggest anything.)
Jay Daley
Jim wrote on 29/07/2004 07:08:15 pm:
> Nope. The smaller the zone, the easier it may be to enumerate with a
> stupid dictionary attack. A serious attempt at enumeration wouldn't
> just do a simple dictionary attack: it would try "generic hyphen
> generic", "generic plus string of digits" and so on. This is no
> different from how most password crackers work. The dumb ones just use
> a dictionary. The clever ones also try manipulations on the names in
> the dictionary: obvious suffixes and prefixes, reversed names, etc,
> etc.
That is precisely my point. As the register grows the namespace becomes
more complex, which then leads to searching ever increasing numbers of
possiblities for ever decreasing results. This appears at first sight to
be a limiting function and what we are all arguing about it where that
limit is. My view, as expressed before is that 99% is wildly optimistic.
Jay
Olaf M. Kolkman
Lets stop going around in circles.
- We all know that enumerating zone data is possible today. Your millage
may vary.
- We all know that NSEC walking will provide you with all names in a zone.
But I do not know what the threat is we try to protect against.
This working group will need to get the requirements for making informed
decisions on how to design NSEC++. Remember that Rip and Ben have
volunteered to put such a list together. Please send your requirements
to these to friendly volunteers. If you have a threat model in mind,
please document and send to Ben & Rip.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html)
Once we have these requirements we can start engineering and figure out
_if_ we can find a solution that meets these requirements. Work that
Miek started may help to make an analysis of the requirements.
Please try to phrase what NSEC++ is expected to deliver and mail your
comments to Ben and Rip.
--Olaf
DNSEXT Co-Chair.
Peter Koch
> The main point of my post is that I can enumerate (for +/- 90%) a zone
> in 24 hours, even if AXFR is blocked.
thanks for this effort, hard data is a Good Thing.
> [ The people interested in this kind of information certainly don't
> mind they can only get 90%. And btw, you really have a hard time
> blocking this... ]
"The people" have different reasons, some of them want a 100% copy and some
of them want near-realtime "diffs". And it's always the last 10% that makes
90% of the price ...
-Peter
Miek Gieben
After seeing much discussion about NSEC2/3 and God knows what, I
deceided to try something completely different. How long would it take
to do a dictionary attack on the .NL zone? And thereby receiving
almost the entire .NL zone without doing an actual AXFR (nor walking
the NSEC chain if NL would do DNSSEC).
I've downloaded 2 dictionary files (apt-get install wdutch
wbritish-large). These are my dictionaries to attack a nameserver. The
dutch and british dictionary contain around 220,000 words. A word
generator could also be written, which would generate sensible (would
be) domain names.
Another small (perl) program walks through theses words. and queries a
NL nameserver. NX domain replies are stored in a seperate file, valid
replies are stored in another.
Thus I've written 2 trivial tools in about half an hour, I downloaded
some dictionaries and I was ready to query a NL server. Total
preparation time: 1 hour.
[ I only tried the NL dictionary, I'm to impatient to wait a whole day
to try all my words... So the calculations may be a bit off, but
general picture should still be correct. ]
Next I fired up the tool and waited. After 46 minutes the whole NL
dictionary was used up. And I had a partial NL zone.
Some numbers:
started: 10:32
finished: 11:18
total running time: 46 minutes
229360 words in 46 minutes, 4986 words/minute.
This yieled 44886 domain names. Which is a succes rate of 19.57%
(estimate) (of the 229360 words)
(there are lies and there is statistics, but 20% of 4986 is about
1000. So you get about 1000 valid domains/minute by doing this).
NL has 1 million domain names, so this gives me only about 5 percent
of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
15 hours), I should get almost the whole NL zone. I haven't look into
this but 80%, maybe 90% sure looks feasible. And the better the
dictionary, the better the results of course. Also the attack is
highly parallel, 2 computers querying 2 different nameserves, would
cut this time in half.
So within a day you can get an AXFR of any zone out there (the bigger
the zone, the more hits you get, the more accurate your "AXFR" will
be). So my question right now is:
Why is so much effort pumped in to a new NSEC solution for DNSSEC when
people can walk DNS zones so easily right now?
Btw, I will be happy to try this out on other TLD's out there :-)
Regards,
Miek
Miek Gieben
> Good work. Interesting result.
>
> > 229360 words in 46 minutes, 4986 words/minute.
> >
> > This yieled 44886 domain names. Which is a succes rate of 19.57%
> > (estimate) (of the 229360 words)
> >
> > (there are lies and there is statistics, but 20% of 4986 is about
> > 1000. So you get about 1000 valid domains/minute by doing this).
> >
> >
> > NL has 1 million domain names, so this gives me only about 5 percent
> > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
> > 15 hours), I should get almost the whole NL zone.
>
well, as I said, statistics == lies.
The main point of my post is that I can enumerate (for +/- 90%) a zone
in 24 hours, even if AXFR is blocked.
[ The people interested in this kind of information certainly don't
mind they can only get 90%. And btw, you really have a hard time
blocking this... ]
So do we want nsec2/3/X to close down the remaining 10% or do we say:
we can live with enumeration in DNSSEC because even in the DNS people
can walk our zone?
grtz Miek
Doron Shikmoni
>NL has 1 million domain names, so this gives me only about 5 percent
>of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
>15 hours), I should get almost the whole NL zone.
>
Could you please explain how you infer this?
Thanks,
Doron
Danny Mayer
>--On 30 July 2004 23:14 +0200 Florian Weimer <f...@deneb.enyo.de> wrote:
>
>>If the data were privacy-sensitive, it couldn't be shared at all
>>without explicit consent from the domain name owner (at least
>>according to most EU law).
>
>Whilst that is true, it isn't true in the sense you imply, as registries
>do demand explicit consent for certain limited disclosures in the
>contract of registration. See for instance:
>
> http://www.nic.uk/ReferenceDocuments/TermsAndConditions/
>
>specifically section 6.1(c). Note the PRSS as described (compressed
>registry) was suspended as a service for (inter alia) privacy reasons,
>and is to be replaced by a public registry search service.
Unless I misread it, this discusses the WHOIS data and says nothing about
DNS which is the subject of this discussion.
Danny
>Alex
Greg Hudson
> But as we said last time we went around this big loop - it isn't just a
> data protection issue, it's also a publication of database copyright issue,
I'd like to understand this point better. Who would be infringing upon
whose copyright?
(Separately, I don't know the status of database copy protection laws
around the world; traditionally, information such as you'd find in the
phone book is not subject to copyright. But my main question isn't
related to that issue; I can't understand how there would be a copyright
issue with a TLD or SLD publishing its own database.)
Florian Weimer
> I am affraid I have lost it now, please enlighten me:
>
> 1. the argument against enumeration is the European (and/or
> other) privacy legislation;
I don't think this is an issue. Most TLD zone data is already
available on request, under terms that aren't too restrictive. This
woul be impossible if domain names were personally identifiable
information.
> 2. it is clear that 99% enumeration on a daily basis is currently
> practice (perhaps not desirable, but real practice);
> 3. NSEC may provide for 100% correct snapshots, valid in the
> interval between zone-updates.
IMHO, the most important question is whether NSEC-based enumeration
causes additoinal load on name servers, or if it might result in less
load.
Stephane Bortzmeyer
Miek Gieben <mi...@atoom.net> wrote
> I've downloaded 2 dictionary files (apt-get install wdutch
> wbritish-large).
Do note that this attack works well against ccTLD (where almost all
the domain names are in the national(s) language(s) or in english) but
not against gTLD, where domain names are in hundreds of different
languages or are made by companies like Interbrand and do not appear
in any dictionary.
> NL has 1 million domain names, so this gives me only about 5 percent
> of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
> 15 hours), I should get almost the whole NL zone.
I am very skeptical about that. The remaining domain names are the
most difficult to guess (Huitema's attack would be better because you
can match on a partial word.)
> this but 80%, maybe 90% sure looks feasible.
I do not believe it.
> Btw, I will be happy to try this out on other TLD's out there :-)
Do not hesitate to try with ".fr", which is much smaller, and tell us
the percentage you get with the wfrench dictionary in Debian.
Damien Miller
> I have seen no claims that NSEC2/3/X can prevent zone walking or
> enumeration. The goal is to make zone walking more expensive.
>
> The lock on my front door does not prevent break-ins. Its goal is to make
> break-ins more expensive.
This is a false analogy: the people who want to enumerate DNS zones
wouldn't be spending their own money - they have zombies and botnets to
do the work for them.
-d
Jim Reid
Geoffrey> Also, I use to think that, even if "NSEC+" were
Geoffrey> available, that NSEC was sufficient for
Geoffrey> {in-addr,ipv6,e164}.arpa. Now I'm not so sure.
These trees are trivially enumerated now. Since they have a well-known
and regular name space, enumerating them is a no-brainer. No variant of
NSEC is going to make enumeration of these zones harder. Or easier.
Alex Bligh
--On 30 July 2004 14:12 +0100 Roy Badami <r...@gnomon.org.uk> wrote:
> Florian> I don't think this is an issue. Most TLD zone data is
> Florian> already available on request, under terms that aren't too
> Florian> restrictive.
>
> My understanding was that there are many ccTLD operators who do not
> make copies of their zones available.
Mine too - further that those who do make it available do prescribe
certain uses contractually, including further publication. I wonder
if CENTR has some stats.
Alex
Alex Bligh
--On 29 July 2004 20:57 +0100 Jim Reid <j...@rfc1035.com> wrote:
> I'm not sure that either is the case. Dictionary attacks will mean
> zone enumeration is always successful, if not always complete.
A successful but necessarily incomplete zone enumeration is in my book an
oxymoron. I am pointing that out not as a cheap shot, but because
enumeration (at least in my book and I think that of those with the
enumeration problem) means the ability to gain a complete or an almost
complete zone through iteration, and we might as well each try and
understand what terminology the other is using.
I do not think there is any dispute that it is possible (without even
having access to nameservers for the the zone) to get a list of domains, a
substantial number of which will be in the zonefile, with that set itself
representing a material portion of the zonefile, for many (but not all)
zonefiles, whether that's by dictionary attack or by textual search of
referring entities (web pages / in-addr.arpa). But that does not equate to
enumeration which (using our terminology) is
a) complete (or very nearly so); and
b) sourced by the organization serving the zone
Seems to me there is a lot of argument here backed by little hard data.
It would be good if (without trashing an xTLDs nameservers) there was
some statistical evidence of what % accuracy/completeness a proposed
attack gave. Let me suggest:
Accuracy% = 100 * ( [PositivelyDiscoveredEntries] - [FalsePositives])
---------------------------------------------------
TotalEntries
as a metric.
Let's bear in mind NSEC as is is 100% assuming an enumeration can be done
between zone updates.
Stephane Bortzmeyer
Paul Vixie <pa...@vix.com> wrote
a message of 83 lines which said:
> 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.
Getting domain names for spamming is one bad use, and one for which
probably 50 % of the zone would be more than enough.
But there are other bad uses (reverse cybersquatting is a good
example, when big corporations try to find domain names looking like
their trademarks in order to harass the holder). And they typically
require more than 50 % of the zone.
Alex Bligh
--On 29 July 2004 19:19 +0100 Jim Reid <j...@rfc1035.com> wrote:
> These trees are trivially enumerated now. Since they have a well-known
> and regular name space, enumerating them is a no-brainer. No variant of
> NSEC is going to make enumeration of these zones harder. Or easier.
I am not sure enumerating ipv6.arpa necessarily has to be trivial (if
there are large delegations) but AFAICS you are right with the others.
Alex
Jim Reid
Stephane> Do note that this attack works well against ccTLD (where
Stephane> almost all the domain names are in the national(s)
Stephane> language(s) or in english) but not against gTLD, where
Stephane> domain names are in hundreds of different languages or
Stephane> are made by companies like Interbrand and do not appear
Stephane> in any dictionary.
Most languages used on the internet have on-line dictionaries.
Lists of brand names, trademarks and so on can be obtained too.
These can easily be compiled into the dictionary used for doing the
zone enumeration or whatever.
Roy Badami
Florian> I don't think this is an issue. Most TLD zone data is
Florian> already available on request, under terms that aren't too
Florian> restrictive.
My understanding was that there are many ccTLD operators who do not
make copies of their zones available.
-roy
Florian Weimer
> The main point of my post is that I can enumerate (for +/- 90%) a zone
> in 24 hours, even if AXFR is blocked.
There are other methods to do that, for example passive DNS
replication: <http://static.enyo.de/fw/volatile/pdr-draft-7.pdf>
If you put a DNS zone on a public, authoritative name server, it is
public. There is no way to change this. Disabling AXFR makes
reconstructing the zone contents somewhat more complicated, but not
impossible (at least for the RRs which are actually used in the wild).
Florian Weimer
> I can't speak for everyone, but we (Nominet) are advised that we have
> a responsibility to protect the confidentiality of data in the .uk zones,
> even if this cannot be done perfectly.
Is this a contractual requirement (mainly to protect companies during
pre-launch phases of new services), or does it follow from privacy
requirements?
Ted Hardie
>Miek Gieben <mi...@atoom.net> writes:
>
>> Why is so much effort pumped in to a new NSEC solution for DNSSEC when
>> people can walk DNS zones so easily right now?
>
>a responsibility to protect the confidentiality of data in the .uk zones,
>even if this cannot be done perfectly.
Can you clarify this? Previous messages from Jay seemed to
indicate that the data which was sensitive was actually the
data in whois, and the DNS protection was needed to prevent
a zone-walk from highlighting domain targets for whois.
If I have that wrong, I would appreciate a clarification.
For those not following CRISP, by the way, iris-core, iris-beep,
and iris-dreg are now all in the RFC editor queue. IRIS has
facilities that allow registries to handle administrative
queries in ways whois does not. Shifting from whois to
iris may solve this problem without going back to
the design phase yet again in DNSSEC.
regards,
Ted Hardie
>Also, I use to think that, even if "NSEC+" were available, that NSEC
>was sufficient for {in-addr,ipv6,e164}.arpa. Now I'm not so sure.
>While any one zone in these hierarchies is trivially enumerable w/o
>NSEC, the elaboration of the aggregate trees is a bigger problem which
>is considerably reduced by NSEC. (Okay, maybe not so hard to elaborate
>e164.arpa yet by any means . . .) The reverse trees and enum may prove
>to be killer apps for NSEC+.
>
>Peter Koch <p...@TechFak.Uni-Bielefeld.DE>
>
>> the last 10% that makes 90% of the price ...
>
>I think this is also a good summation.
>
>Regards
>
>Geoff
Miek Gieben
> On Wed, Jul 28, 2004 at 09:05:31PM +0200, Miek Gieben wrote:
> > How long would it take
> > to do a dictionary attack on the .NL zone?
>
>
> > Next I fired up the tool and waited. After 46 minutes the whole NL
> > dictionary was used up.
> > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
> > 15 hours), I should get almost the whole NL zone.
>
that's probably because the extrapolation is mathematical nonsense.
The point I was making is that:
1) with no effort at all, I can get a listing zones, with
more effort I can probably get a longer listing.
2) those people who think enumeration is going to be a problem
in DNSSEC are saying/claiming enumeration isn't a problem
in the DNS?
> dictionary you obtained 5% of the domain names. How do you propose
> obtaining the other 95%, or even 80% of the rest?
modifying John the Ripper to attack a nameserver instead of a local
passwd file? I've played with john the ripper a few years ago, it's
lots of fun to run the incremental mode on a passwd file :-)
That said. I'm way too lazy to do this. My point is/was that there
are other ways to get a zone, besides AXFR and NSEC walking.
<snip>
> I wager that right now someone wanting to find domains will find it more
> cost-efficient to simply scan web server logs, running a spider on search
> engine results, or doing in-addr.arpa lookups based on assigned netblocks.
I agree. And with some windows zombie hosts on the Internet this will
all go a lot faster still.
So dictionary attacks + spidering web logs + google attacks +
in-addr.arpa lookups will get you 80%/90% of a zone?
> Obtaining 5% of a zone through an efficient method of guessing is
> interesting. However, I am not sure this is sufficient in itself to
> argue that limiting zone walking is inherently useless.
>
> On the other hand, if enough people really want a list of domains badly
> enough to waste 50TB, 500bn DNS queries and several months gathering
> it, then I think it would be better for the network as a whole for
who says this isn't happening right now? If someone really wants to know
I propose the following experiment (for a TLD).
* Measure your current nameserver load
* Put your zone on a anonymous FTP site
* Measure your nameserver load again
If the load is lower I'm right, if the load is higher some else is
right :-)
> the registries to consider either selling the data or making it freely
> available.
wonderfull idea,
grtz Miek
Jay Daley
Either because it was posted by a non-subscriber or because it contained
to many characters (> 20000).
With the massive amount of spam, it is easy to miss and therefore
delete posts that need manual approval.
Please fix your subscription addresses or shorten your postings by adding
links instead of attachments ]
Ted
Ted wrote on 29/07/2004 10:28:08:
> I am not sure what you call "a large zone", so also not if .nl
> qualifies (it is in the top-5 or so of largest zones, but, of
> course, much smaller than .com).
> The .nl domain has some 1.3M delegations, some 30k domains are
> newly registered and some 5k are released per month (from data
> over the first few months of 2004).
That will do.
>
> I know of a number of registrars who keep daily updated, and
> very accurate lists of registrered and returned domain names.
> For .nl and also for other TLDs.
>
> These guys use various techniques to keep their lists accurate
> and up-to-date. Although highly effective, these techniques are
> neither complicated, nor costly for the registrar.
> However, their load the .nl nameservers is significant, and thus
> one can easily see and determime who/what is causing it in the
> nameserver-traces which we routinely investigate in our testlab.
With respect this is still anecdotal. Where is the real data? i.e. "By
dictionary attack X managed to guess Y% of the 1.3m names".
Jay
Jim Reid
Jay> When people register a name they use a name from a pool of
Jay> possible names. As a zone grows in size people begin to
Jay> exhaust the easy pools and so need to invent new pools. So
Jay> the initial pools are often
Jay> very short names (2, 3, 4 characters)
Jay> generic words (eg music, buses, teeth)
Jay> organisation/personal names
Jay> but as these grow people start to invent new ones
Jay> generic hyphen generic
Jay> generic plus number
Jay> and so on.
Jay> So the smaller a zone is, the easier it is to enumerate.
Nope. The smaller the zone, the easier it may be to enumerate with a
stupid dictionary attack. A serious attempt at enumeration wouldn't
just do a simple dictionary attack: it would try "generic hyphen
generic", "generic plus string of digits" and so on. This is no
different from how most password crackers work. The dumb ones just use
a dictionary. The clever ones also try manipulations on the names in
the dictionary: obvious suffixes and prefixes, reversed names, etc,
etc.
--
Florian Weimer
> But there are other bad uses (reverse cybersquatting is a good
> example, when big corporations try to find domain names looking like
> their trademarks in order to harass the holder).
This is completely legal and has to be part of any effort to protect a
trademark. I suppose that most organizations concerned with trademark
protection already systematically scan copies of the most important
zones.
Roy Badami
Alex> I am not sure enumerating ipv6.arpa necessarily has to be
Alex> trivial (if there are large delegations) but AFAICS you are
Alex> right with the others.
I don't think large delegations make a difference. You can
distiniguish empty non-terminals from non-existent domains.
So when you walk the tree you stop descending only when you get
NXDOMAIN. If you get no records back, but no error, then you know
there's something below that point in the tree, and carry on
descending.
-roy
Jim Reid
Jay> That is precisely my point. As the register grows the
Jay> namespace becomes more complex, which then leads to searching
Jay> ever increasing numbers of possiblities for ever decreasing
Jay> results. This appears at first sight to be a limiting
Jay> function and what we are all arguing about it where that
Jay> limit is.
I'm not sure that either is the case. Dictionary attacks will mean
zone enumeration is always successful, if not always complete. There
are other ways of enumerating a zone that have been mentioned in this
list a while ago. Zone enumeration is already going on. And presumably
the results of that are "good enough" for whoever is doing the
enumeration, whether they're getting 1% or 100% of the zone.
It would be good to know how effective a concerted dictionary attack
would be on some TLD. But I don't see this making much of a difference
to the wider debate. Those who oppose NSEC because of the zone
enumeration issues are unlikely to change their minds if a decent
dictionary attack -- just one means of enumerating a zone remember --
yields 80% or 90% or 100% of the zone.
Andras Salamon
> How long would it take
> to do a dictionary attack on the .NL zone?
Thanks for reporting this experiment, very interesting.
> Next I fired up the tool and waited. After 46 minutes the whole NL
> dictionary was used up.
> NL has 1 million domain names, so this gives me only about 5 percent
> of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~=
> 15 hours), I should get almost the whole NL zone.
I don't understand your extrapolation here. Given a reasonably large
dictionary you obtained 5% of the domain names. How do you propose
obtaining the other 95%, or even 80% of the rest?
Do you have another dictionary that is likely to give you a 20% hit rate
_and_ coverage of the rest of the namespace? You could certainly create a
new dictionary of, say, 500K words formed by adding the English dictionary
to the Dutch one, and adding common domain suffixes like 123 or prefixes
like 0800. If you then take the concatenation of every string in this
dictionary with every other string (as well as insertion of '-' between
the strings), you get a dictionary of 2*250*10^9 (500 billion) possible
domain names. However, you are going to get at most a 10^6/(5*10^11) =
2*10^(-6) hit rate for this dictionary even with 100% coverage. So you
would get at most 100*5*(10^3)*2*10^(-6) = 1 domain name per 100 minutes
even with 100% coverage. If you parallelise, say 100 queries at a time,
that's still only 1 name per minute. Hence, this method is not likely
to help those "direct marketers" who are looking out for the new names
being registered (this was cited by people on this list as a bogey man).
This method will only help those who want a rough list once (and are
prepared to wait several months and generate around 50TB of network
traffic to build it, at 100 bytes per query).
I wager that right now someone wanting to find domains will find it more
cost-efficient to simply scan web server logs, running a spider on search
engine results, or doing in-addr.arpa lookups based on assigned netblocks.
Obtaining 5% of a zone through an efficient method of guessing is
interesting. However, I am not sure this is sufficient in itself to
argue that limiting zone walking is inherently useless.
On the other hand, if enough people really want a list of domains badly
enough to waste 50TB, 500bn DNS queries and several months gathering
it, then I think it would be better for the network as a whole for
the registries to consider either selling the data or making it freely
available.
-- Andras Salamon and...@dns.net
Alex Bligh
--On 29 July 2004 13:58 +0200 Ted Lindgreen <t...@NLnetLabs.nl> wrote:
> Please explain to us why NSEC2/3/X is REALLY needed, instead of
> asking us to prove the obvious.
Sorry, unless I'm dropping mail message you have not shown that over x% of
the zone file can be obtained through dictionary attacks in a small amount
of time, where x is a large number (let's say 90% or 95%). Mark Gieben
acknowledged this in the post where he said "Statistics==Lies".
You have merely shown where x is a small number, it can be obtained, and
extrapolated. For the reasons posted on this list, and which indeed should
be obvious, if you can find (say) 25% if (say) 10 hours, that by no means
suggest you can find 90% in less than 40 hours.
The reasons for the requirement for non-traversal of zones (NSEC2/NSEC3)
have been expounded at great length; I don't see any purpose in repeating
them again. As far as I can tell, the w/g reached consensus that there was
a requirement (perhaps not one you have) but that it would not form part of
DNSSECbis.
You have neither demonstrated that that requirement has gone away (as even
if you could demonstrate the .NL zone file can be recovered 100% accurately
by dictionary attack in a small amount of time, that does not necessarily
extinguish a requirement elsewhere - see comment on .com), nor have you
demonstrated that your original thesis (that nearly all of the zone
contents could be retrieved by dictionary attack) is true.
If it's true that you don't have the resources or appetite to perform your
statistical test, can I suggest you post your perl programs and methodology
in detail, and let someone else demonstrate whether or not a dictionary
attack can actually reveal let's say over 95% of a zone file, and the
number of queries it took.
The whole thesis of those proposing NSEC2/3 has been that DNSSEC should not
make the situation substantially WORSE. If it is the case that existing
attacks are just as easy to perform by the attacker as NSEC enumeration,
then that would have some weight. We already know dictionary attacks cannot
in the general case yield a complete zone. Your suggestion that they can
yield a nearly complete zone (for values of nearly like 95%) for effort
comparable with an NSEC enumeration is at the moment not supported by any
data I have yet seen - if it is incorrect, it's probably also disprovable.
If you are going to claim you have a new argument based on new data, please
supply that data, not go half way then claim you are neither "founded
or funded" to produce the relevant results.
Alex
Alex Bligh
--On 29 July 2004 22:18 +1000 Damien Miller <d...@mindrot.org> wrote:
> This is a false analogy: the people who want to enumerate DNS zones
> wouldn't be spending their own money - they have zombies and botnets to
> do the work for them.
Though TBF that is the case for both dictionary attacks AND nsec
enumerations.
Alex Bligh
--On 31 July 2004 10:47 -0400 Greg Hudson <ghu...@MIT.EDU> wrote:
>> But as we said last time we went around this big loop - it isn't just a
>> data protection issue, it's also a publication of database copyright
>> issue,
>
> I'd like to understand this point better. Who would be infringing upon
> whose copyright?
>
> (Separately, I don't know the status of database copy protection laws
> around the world; traditionally, information such as you'd find in the
> phone book is not subject to copyright. But my main question isn't
> related to that issue; I can't understand how there would be a copyright
> issue with a TLD or SLD publishing its own database.)
It isn't about the TLD infringing it's own copyright, it's about later
enforceability of copyright. IANAL but AIUI it works this way: there is a
separate copyright on a compilation and/or database than on its constituent
items. So if, for instance, you compile and publish a compendium of poetry,
you hold a copyright on the compiled work, even though you may only have a
license to use the poems therein. [I think database copyright is
technically different from compilations but not such that it matters here].
If, however, you then publish the work to all and sundry without specific
terms of license, it dilutes your ability to enforce license terms against
use of the work later.
As a concrete example (which I could not comment on before as it was at
trial), Nominet recently took action in Australia against a number of
companies and individuals allegedly involved in a data mining attack;
Nominet alleged the information was then used, inter alia, for provision of
misleading invoice-like documents, contrary to various Australian trade
practices legislation (I think you can guess the picture). 4 out of 5 who
admitted liability just prior to trial, one went to trial and we await
verdict. We have taken similar action before, and will continue to do so in
the future (even though they may each cost many hundreds of thousands of
dollars if not more) on public policy grounds. How they got the data is not
relevant here, but, at least for some of the claims, a key factor was not
only that they obtained copies of a database, but also that they had a no
license to do so. If it were the case that we published the database as a
whole without license requirements (i.e. without proscribing the activity a
malefactor performed), it would make it harder to make a successful claim
which rested on the use of the database without license. For these
purposes, it is not necessarily relevant whether some fraction of the
database (even a large fraction) could be compiled from other sources (for
instance Paul's in-addr.arpa or google logs), because Nominet would not
themselves be publishing those - that's someone making their own
compilation. The reason for the public policy is many fold, but for one,
those supplying the data that generates the compilation do so on the basis
of it being used for certain purposes, and not for others - they simply
don't want the data they supply used for spam, scams, etc.; that's not a
legal driver (so if Nominet were a for-profit body after the last dollar
possible this problem would no doubt be solved in the market place for a
suitable number of $), that's a policy driver.
There are some other issues to do with the triangular relationship between
governments, ICANN and ccTLDs - see all the hoo-haa about ccTLD zonefile
escrow a year or two ago - but I don't propose to go into those here as
they are long and seriously off-topic. Drop me a line off list if you
really want to know.
Florian Weimer
> --On 30 July 2004 14:12 +0100 Roy Badami <r...@gnomon.org.uk> wrote:
>
>> Florian> I don't think this is an issue. Most TLD zone data is
>> Florian> already available on request, under terms that aren't too
>> Florian> restrictive.
>>
>> My understanding was that there are many ccTLD operators who do not
>> make copies of their zones available.
>
> Mine too - further that those who do make it available do prescribe
> certain uses contractually, including further publication.
If the data were privacy-sensitive, it couldn't be shared at all
without explicit consent from the domain name owner (at least
according to most EU law). Certainly most registries, registrars and
DNS service providers don't share this view.
There might be other reasons to keep zone data confidential. If this
is the case, they should be named. Privacy concerns are not an excuse
for everything. 8-)
Alex Bligh
--On 30 July 2004 23:14 +0200 Florian Weimer <f...@deneb.enyo.de> wrote:
> If the data were privacy-sensitive, it couldn't be shared at all
> without explicit consent from the domain name owner (at least
> according to most EU law).
Whilst that is true, it isn't true in the sense you imply, as registries
do demand explicit consent for certain limited disclosures in the
contract of registration. See for instance:
http://www.nic.uk/ReferenceDocuments/TermsAndConditions/
specifically section 6.1(c). Note the PRSS as described (compressed
registry) was suspended as a service for (inter alia) privacy reasons,
and is to be replaced by a public registry search service.
Alex
Roy Badami
Florian> If the data were privacy-sensitive, it couldn't be shared
Florian> at all without explicit consent from the domain name
Florian> owner (at least according to most EU law).
That's an oversimplistic view of data protection legislation. One of
the principles in the UK implementation is that personal data can only
be used for the purposes for which it was collected. There isn't a
binary private/not-private flag; it's very much about exactly what
you're allowed to do with the data that you (legitimately) have, based
on what the purpose of collecting the data was, what you told the data
subjects, what (if any) consent you got from the data subject, what
contractual obligations you have to them, etc.
I'm not making any suggestion as to how (if at all) data protection
legislation impacts the issues being discussed here; just that many
people seem to have an oversimplistic view of what EU data protection
legislation is all about.
In particular, in previous threads, people have claimed that
particular issues _obviously_ couln't be an issue with data
protection... Any statement like that rings alarm bells; anyone who's
worked with this stuff is unlikely ever to say that something which
involves data that might even remotely relate to people is _obviously_
OK.
I wish people wouldn't believe that the law is as simplistic as
"you're either allowed to publish this or you're not". No law works
like that. Quite aside from the fact that although we talk about
"publishing infomation in the DNS", a service that answers queries
doesn't correspond to the traditional legal notion of publishing, and
may well not be regarded as such. AXFR or NSEC may well be more
likely to constitute publishing.
Though in the UK, in the light of the recent case Durant v FSA, I'd be
inclined to believe that zone files aren't personal data. I'd have
been far less confident of that last year, though.
IANAL, of course.
-roy
Eric Brunner-Williams in Portland Maine
> exactly what you're allowed to do with the data
This issue was debated at length in the provreg wg. You may not know
this, and may not appreciate the outcome.
In a nutshell, a policy object was adopted for provisioning sessions,
proximal to the p3p compact policy, and a binary toggle was added at
the last minute on data elements. I'm the author of the first proposal,
and I'll let you discover who was the author of the second, and infer
the process issues.
The context was publication via :43, and more generally, bulk transfer
and any other publication mechanism, including zone file publication,
and the protocol EPP.
Cheers,
Eric
Jim Reid
Alex> A successful but necessarily incomplete zone enumeration is
Alex> in my book an oxymoron.
We can agree to differ. IMO a successful zone enumeration is one that
achieves the goals of whoever is doing the enumeration. That may well
be the whole zone. But it might be the set of names that exist between
iam.co.uk and izm.co.uk.
Alex Bligh
--On 30 July 2004 21:11 -0400 Danny Mayer <ma...@gis.net> wrote:
>>> If the data were privacy-sensitive, it couldn't be shared at all
>>> without explicit consent from the domain name owner (at least
>>> according to most EU law).
>>
>> Whilst that is true, it isn't true in the sense you imply, as registries
>> do demand explicit consent for certain limited disclosures in the
>> contract of registration. See for instance:
>>
>> http://www.nic.uk/ReferenceDocuments/TermsAndConditions/
>>
>> specifically section 6.1(c). Note the PRSS as described (compressed
>> registry) was suspended as a service for (inter alia) privacy reasons,
>> and is to be replaced by a public registry search service.
>
> Unless I misread it, this discusses the WHOIS data and says nothing about
> DNS which is the subject of this discussion.
Section 6 says what may be done with personal data (including whois and
PRSS). I made the point as Florian was arguing that "if the zonefile can be
ftp'd under contract, there cannot be a problem with enumeration". That is
simply not the case, as contracts of registration (in the UK and elsewhere)
provide for certain data to be given to limited numbers of other people
under the safeguard of contract - which is entirely different from giving
that data to anyone. Straight from the EU directive that drove the
implementing legislation (for instance) you cannot export the data outside
the EU without certain protections. So sadly Florian's argument (that if
you can ftp under contract lawfully, there is necessarily no problem with
enumerability) is just plain wrong in law.
A much better argument to make Florian's point would be that the data is
not personal data. That is at least arguable. Our advice is that it may
well be.
But as we said last time we went around this big loop - it isn't just a
data protection issue, it's also a publication of database copyright issue,
and a POLICY issue on (inter-alia) privacy, It is entirely possible that
(for instance) site-finder infringed no national law, but offended the
internet community's views on policy.
I am not sure this "why is there the requirement" debate is either
productive or useful. I'd prefer we did "what is the requirement" (from
those who have it), and what are the proposals to fix it. Then, if some
have the requirement, and others, incomprehending of the reasons for it
(and who knows perhaps they are right) don't, it boils down to "does the
next revision of the protocol include the option". No-one has yet suggested
an enumerability option is a bad thing, apart from the protocol complexity
it generates.
I use requirement in the singular above - however, if we are reopening cans
of worms, I would have thought it might be a useful requirement for large
zone file operators to have features which minimize the CPU required to
sign zonefiles where a minimum number of the delegations themselves require
signing - this would ease transition to DNSSEC and encourage deployment; I
note that sub 5 minute zone updates are now becoming the norm (or at least
are on people's near term work plans), whereas they weren't (AFAIK) when
this was last discussed. I have deliberately phrased the above without
mentioning previously suggested implementations or -arends.
Alex
Olaf M. Kolkman
Dear Colleagues,
I returned from vacation and saw that this thread, and the related
"What I mumbled at the mike today" had developed during my absense. I
started reading it with the intention to make an abstract of the
discussion. The shear amount of side tracks and circles in arguments
make this virtually impossilbe. I counted 191 messages with a total of
15127 lines (including headers).
I want to close this thread by giving every participant the
opportunity to state their concluding argument in not more than 20
lines of text.
Please make an abstract of your own concluding arguments (some people
may have changed their opinions) please do not start discussing these
arguments again. If you can phrase your arguments as a set of
(measurable) requirements for further protocol development that would
be fab.
Note that we are trying to take the work on preventing zone
enumeration seriously and that we are trying to get the requirements
done. At least one of the messages burried in the thread was relevant to
that and didn't get any followup.
Also read:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html
I am trying to get something sensible out of this that will allow us to
go forward or, if needed, conclude, in a decent fashion.
-- Olaf
DNSEXT Co-Chair.
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
Ben Laurie
> "Olaf M. Kolkman" <ol...@ripe.net> writes:
>>I want to close this thread by giving every participant the
>>opportunity to state their concluding argument in not more than 20
>>lines of text.
>>I am trying to get something sensible out of this that will allow us to
>>go forward or, if needed, conclude, in a decent fashion.
>
>
> 2:
> 3: - non-registry (SLD, et al) zone administrators are already
> 4: hiding their sensitive DNS data, if any, behind split views
> 5:
> 6: - registry (mostly TLD) zone administrators have a competitive
> 7: interest in name secrecy not shared by registrars/registrants
I don't believe "competitive" is a correct characterisitaion for all
registries, though it may be for some, and I'm not sure I agree that
registrants do not share this interest, either. Certainly registrants
register domains in order that a particular audience can see those
domains, but that does not mean that all registrants want their domains
to be visible to absolutely everyone.
For example, I have just registered a domain in order to get email - if
I want to receive email from you, then I'll tell you what it is. If I
don't, I won't. Having it published doesn't help me achieve that.
> 9: - load increases due to more difficult enumeration will be felt
> 10: by enumeration victims and third parties, not just attackers
> 11:
> 12: my recommendations are:
> 13:
> 14: + ensure that NSEC is capable of covering a single name, so that
> 15: a zone can use precomputed positive signatures and on-the-fly
> 16: negative signatures, and let motivated/interested zone
> 17: administrators add name secrecy by provisioning extra hardware.
> 18:
> 19: + consider other, more compact encodings for nonexistence-proof,
> 20: which are easier to generate on-the-fly than single-name NSEC.
Why are you only interested in on-the-fly proofs? If its to avoid
(major) changes to the protocol, then there's at least one problem with
this type of solution, which is that outsourced DNS servers would have
to have a signing key capable of signing anything.
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
Olaf M. Kolkman
I would like to conclude this thread. Please send your (about) 20
lines closing argument and try to refrain from discussing other
persons summaries.
-- Olaf
Danny Mayer
>I don't believe "competitive" is a correct characterisitaion for all
>registries, though it may be for some, and I'm not sure I agree that
>registrants do not share this interest, either. Certainly registrants
>register domains in order that a particular audience can see those
>domains, but that does not mean that all registrants want their domains to
>be visible to absolutely everyone.
I'm curious. Why would they register a domain if they didn't want
everyone to know about it? After all registering a domain means publish,
make it public and provide a means to get there. There are other ways
to provide directions to a site without registering it.
>For example, I have just registered a domain in order to get email - if I
>want to receive email from you, then I'll tell you what it is. If I don't,
>I won't. Having it published doesn't help me achieve that.
So don't register the domain. You can always just provide an IP address.
Mail servers only use the domain name to find out where to deliver the
mail.
Danny
Paul Vixie
> I want to close this thread by giving every participant the
> opportunity to state their concluding argument in not more than 20
> lines of text.
> ...
> I am trying to get something sensible out of this that will allow us to
> go forward or, if needed, conclude, in a decent fashion.
1: my observations are:
2:
3: - non-registry (SLD, et al) zone administrators are already
4: hiding their sensitive DNS data, if any, behind split views
5:
6: - registry (mostly TLD) zone administrators have a competitive
7: interest in name secrecy not shared by registrars/registrants
8:
9: - load increases due to more difficult enumeration will be felt
10: by enumeration victims and third parties, not just attackers
11:
12: my recommendations are:
13:
14: + ensure that NSEC is capable of covering a single name, so that
15: a zone can use precomputed positive signatures and on-the-fly
16: negative signatures, and let motivated/interested zone
17: administrators add name secrecy by provisioning extra hardware.
18:
19: + consider other, more compact encodings for nonexistence-proof,
20: which are easier to generate on-the-fly than single-name NSEC.
--
Paul Vixie
Paul Vixie
> > > I want to close this thread by giving every participant the
> > > opportunity to state their concluding argument in not more than 20
> > > lines of text.
i said:
> > 1: my observations are:
> > ...
> > 12: my recommendations are:
> > ...
> > 20: ...
someone else said:
> [whatever]
but i'm not debating these topics. olaf asked me to state my concluding
argument in 20 lines or less, which i've done. anyone who has a different
view, whether outright opposed to what i said or completely independent,
ought to give olaf 20 lines (or fewer) of text. as tempting as it is to
stand my ground and fight for what i believe in, that time, for nsec++, is
over.
Alex Bligh
--On 06 September 2004 13:16 -0400 Danny Mayer <ma...@gis.net> wrote:
> I'm curious. Why would they register a domain if they didn't want
> everyone to know about it?
I have to agree with Olaf's comment that this discussion is becoming
circular - this in particular has been covered at great length (from both
directions) before. Whilst I'm always happy to discuss Nominet's policies
etc. Olaf has made the point this is not / no longer the place to discuss
the rationale behind it. Can I suggest we either take this off-list, or go
dig up things from the archive, and provide closing statements/arguments as
requested?
Alex
Alex Bligh
--On 01 September 2004 11:14 +0200 "Olaf M. Kolkman" <ol...@ripe.net> wrote:
> I want to close this thread by giving every participant the
> opportunity to state their concluding argument in not more than 20
> lines of text.
[ This is a response from me personally and not from Nominet/Geoff/Ben;
apologies for it being 21 lines ]
=====
Defense against Zone Enumeration is desirable for reasons including:
1. Principle of least surprise - Current DNS implementations allow it
2. Many users require it, e.g: certain registries who for honestly held
policy reasons (expounded at length, but outside IETF's remit to debate);
enterprise uses where split DNS is not feasible (e.g. web services).
3. For both, there is a qualitative difference between publishing a node &
associated RRs, and publishing an index of all nodes. For the former, and
possibly the latter, discovery of a significant number of RR's is less
undesirable than discovery of a complete or near complete zone.
4. Those registries that publish data normally do so under specific Ts&Cs,
and would chose mechanisms more efficient than DNSSEC enumeration.
5. The argument that the data is freely available "anyway", through
(for-instance) dictionary attacks, web-server logs etc. has not been
supported by empirical evidence; what empirical evidence has been put
forward suggests that not all zones are significantly susceptible to
dictionary attack, and those that are, are far from wholly susceptible.
I recommend that there should be an optional server side alternative
mechanism for authenticated denial that does not expose an index to the
zone contents, but retains protection against replay attack, and without
online signing of denials (impractical, computationally expensive, DoS
vector). This should be based upon NSEC, and making as few changes as
possible.
=====
Olaf M. Kolkman
Roy Badami <r...@gnomon.org.uk> wrote:
> However Olaf contacted me privately requesting
For the record this was my request:
Hello,
I am sending this message to a few people that where had an
outspoken meaning in this discussion. With reference to
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01600.html
would you mind giving a 20 lines conclusion of your arguments?
Thanks,
-- Olaf
Roy Badami
I hadn't been intending to respond to the chairs' call for 20-line
summaries, since I regard myself as an intersted bystander rather than
an active WG member... However Olaf contacted me privately requesting
I do so, so here goes...
--------
I regard it as highly desirably to reach some sort of consensus that
includes those ccTLDs that have concerns about enumeration, and
realistically I think that means addressing their requirements, rather
than convincing them to change their requirements. I'm pleased that
the co-chairs seem to concur that this is worth persuing...
I don't have any strong feelings as to the shape that the technical
solution should take though I note that Bloom filters have been
completely neglected in recent discussions, and I think they may still
be of possible value -- see for example Steve Bellovin's ID
http://www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt
I would argue that authenticated denial is important in a TLD, and
that provably-insecure delegations are vital, as without them the
level of security offered to customers of that TLD is diminished.
I note also that if some TLDs choose not to offer these security
guarantees, then there will be no incentive for their customers to
migrate away from transitional mechanisms such as Paul Vixie's DLV
(which does offer those guarantees, at least to participating resolvers).
-roy
Miek Gieben
Hello,
I could only manage to write 17 lines :-) But here is goes:
First of all, any solution to be found for the "problem" of enumeration is
a solution that will only work for 50% (as there are other ways of getting
the data). If think a protocol change is a big sacrifice for a non optimal
solution.
Secondly only a few TLD's have expressed their concern about this, which is,
IMO, again another reason not to fiddle with the protocol.
That said, I also take the view that enumeration in DNSSEC should not be made
easier than it is today.
The requirements from Ed [1] are a good starting point. But as Ed said
- you will never have a solution that will satisfy all these
contraints.
[1]
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01610.html
grtz Miek
Jelte Jansen
--start line count--
I think Lewis summed it up pretty well, and I don't see any way to
satisfy all these constraints either, it would be great if someone else
would. One of the biggest problems I have with all this is that DNS(SEC)
is complicated enough as it is, and we should be really really really
sure that it is a problem (...of DNS (...on the protocol level)), before
we start adding yet more complexity to it all (which is a security risk
itself).
For those who have problems with enumeration, online signing shall
probably not be a solution either, but muddying up the namespace will
not make administrating zones any easier. Insofar i have read the
proposals I have serious doubts if they solve the enumeration problem,
but that can probably be fixed, and I haven't given them much attention
(see above).
The 5 requirements mentioned by Lewis should be at least present in the
requirements documentation, be it as hard requirements or strong
considerations, as the trade-off for any solution should be well considered.
-- line 20 --
Jelte
Peter Koch
> lines of text.
Zone file enumeration is a deployment obstacle for DNSSEC and it should be
made no easier than it is without DNSSEC. I'd also like to steal from
Ed Lewis' excellent set of items to avoid (sorted kind of top down):
o Exposition of any existing names (regardless of data owned)
o Breaking namespace invariants ("muddying up the name space")
or namespace consistency
o Opening attacks against positive answers or against authenticated
denial of RRSet existence
o Exposition of more than a very limited number of not existing names
o Protocol incompatibilities other than TCR
o Enforcing major operational efforts by those satisfied with NSEC
o Enabling replay attacks for authenticated denial
As long as complexity allows, zone enumeration avoidance may be optional
since not only the structured {IN-ADDR,IP6,E164}.ARPA zones but also the
majority of zones containing no more than @, "www" and maybe "mail" won't
probably need it. Defining a set of reasonable prerequisites (e.g. "no
wildcards", "delegation only", etc) is acceptable.
-Peter
Mark Andrews
>
>
> --On 10 September 2004 07:58 +1000 Mark Andrews <Mark_A...@isc.org>
> wrote:
>
> > I dislike the hashing solutions as it introduces namespace
> > pollution and doesn't allow all existing DNS zones to be signed.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> At the risk of annoying Olaf, but for the purposes of getting a common
> understanding of all our position, could you elaborate on the bit
> underlined by carrets? (i.e. either it's a new point or I've completely
> missed something).
>
> Alex
If I have a zone with domainnames/zonename that are almost
maximal length the addition of the hash causes the resulting
domainnames to exceed maximimal length.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Alex Bligh
--On 10 September 2004 07:58 +1000 Mark Andrews <Mark_A...@isc.org>
wrote:
> I dislike the hashing solutions as it introduces namespace
> pollution and doesn't allow all existing DNS zones to be signed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
At the risk of annoying Olaf, but for the purposes of getting a common
understanding of all our position, could you elaborate on the bit
underlined by carrets? (i.e. either it's a new point or I've completely
missed something).
Alex
--
Marcos Sanz/Denic
> I want to close this thread by giving every participant the
> opportunity to state their concluding argument in not more than 20
> lines of text.
Overcoming my original reluctance to give a summary of my position,
because the chairs did not privately contact me to do so *lol*, here it
goes:
The current list of requirements (
http://www.links.org/dnssec/requirements.txt) reflects my expectations for
a signed proof of non-existence (modulo my remarks sent privately to the
authors 3 weeks ago: ICMP_ECHO_REQUEST), so I won't list the requirements
here again. IMHO some of them are less and some are more relevant, but it
has repeatedly been said that we are still in the phase of outspeaking
requirements, and we all know that a solution will probably imply a
trade-off among them.
Best,
Marcos
Alex Bligh
--On 10 September 2004 14:59 +0100 Jim Reid <j...@rfc1035.com> wrote:
> Another potential problem with the current hashing proposals is that a
> hash could collide with a label for an existing name. ie Suppose the
> hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo
> already exists as a delegation point or CNAME.
Let's append ".*" to each hash label to ensure it doesn't collide then.
(joke).
Alex
Jim Reid
Mark> If I have a zone with domainnames/zonename that are
Mark> almost maximal length the addition of the hash causes the
Mark> resulting domainnames to exceed maximimal length.
Another potential problem with the current hashing proposals is that a
hash could collide with a label for an existing name. ie Suppose the
hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo
already exists as a delegation point or CNAME.
--
Simon Josefsson
> Another potential problem with the current hashing proposals is that a
> hash could collide with a label for an existing name. ie Suppose the
> hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo
> already exists as a delegation point or CNAME.
There are at least two solutions to that problem.
The first is to use salting to make sure there are no collisions.
The second one is to place the NSECbis record in a separate name
space. For example:
jim.foo IN A
alex.jim.foo IN CNAME ...
alex._no.foo IN NSECbis ....
The second solution introduce new issues, like decreasing the length
of the owner name by 3 bytes compared to naive hash based NSECbis.
However, the second solution also has additional advantages. You can
delegate the ._no. zone, to serve all NSECbis records from separate
machines, which can be useful for dynamic NSECbis signing.
Thanks,
Simon
PS. All of this has been mentioned before. It seems like a process
failure that we keep repeating these discussions.
Robert Elz
From: Simon Josefsson <j...@extundo.com>
Message-ID: <ilusm9q...@latte.josefsson.org>
| There are at least two solutions to that problem.
no, there are no solutions for this problem in any proposal that requires
adding new names (attempts to steal some of the namespace) for any existing
RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're
relevant only to SRV lookups and don't prevent _tcp being used as a label
for any other RR types).
| The first is to use salting to make sure there are no collisions.
That doesn't work, you just collide with a different name. For any
name that you propose adding, I simply add the same name with whatever
RR types cause your proposal to have problems.
| The second one is to place the NSECbis record in a separate name
| space.
In this case the "separate name space" is the name that is the problem.
| PS. All of this has been mentioned before. It seems like a process
| failure that we keep repeating these discussions.
Perhaps, but if people keep not understanding, there's little choice but
to keep on repeating. Eventually the message might get through.
kre
Ben Laurie
> I want to close this thread by giving every participant the
> opportunity to state their concluding argument in not more than 20
> lines of text.
The central idea is that people should not be worse off by deploying
DNSSEC than they are by deploying DNS, So, zone file enumeration should
be no easier in DNSSEC than it is in DNS.
That said, DNSSEC introduces other considerations, in particular the
potential exposure of private keys, so a solution should not require
private keys to be kept online.
And then there are "ordinary" DNS requirements: the solution should be
compact and minimise change to existing protocols. If it introduces
extra processing, storage or bandwidth requirements, it should also be
optional.
Cheers,
Ben.
"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
--
Mark Andrews
I doubt there is a perfect solution that will solve everyones
problems. There may need to be a suite of solutions that
the zone administrator can choose between.
DNSSEC and DNS itself is a set of engineering tradeoffs.
DNSSECbis just changes the the current set of tradeoffs.
Spoofing (DNS) vs enumeration (DNSSEC/DNSSECbis)
I dislike the hashing solutions as it introduces namespace
pollution and doesn't allow all existing DNS zones to be signed.
I can live with online signing though I don't believe that
NSEC white lies is the best way to do this. If we have to
have online signing then we should look for a better way
to do this than NSEC white lies. I believe we can introduce
a new type of zone signing and have no impact on DNSSECbis
servers. The zones would be treated as unsigned by DNSSECbis.
This would give the zone operator the choice of spoofable
results, enumeration or online signing. I don't believe
that the other tradeoffs are the way to go. We already
have online signing for secure updatable zones.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Robert Elz
From: Alex Bligh <al...@alex.org.uk>
Message-ID: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]>
| [ I hope Olaf's going to forgive me on this one, but I think we are
| now talking about something quite different from the circular
| discussion on whether or not non-enumerability is needed and
| what the requirements are so I have changed the subject appropriately ]
Yes, I have been avoiding that discussion, I believe my views are already
well known (and that I haven't been wasting space restating them doesn't
mean they've changed).
| I'm lost. Let me do some CS/Math and then see if I have applied it
| without missing the point:
|
| If you have a set of labels X, and a set of labels Y where
| Y(i) = HASH ( X(i) , S, H)
|
| i.e. a hash of X(i) using salt S (the same for all values of i) and H bit
| hash, then, providing n(X) << 2^H,
Well, you've already lost the "any zone" requirement with that
assumption, but it gets worse than that.
| it's trivially easy (and computationally
| efficient) to find a value S such that there are NO values i, j such that
| Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that
| there are no collisions between the range and domain of the hash function.
I think you're relying upon probabilities, which doesn't work in a situation
like this.
| One possible mechanism is simply to iterate through values of S chosen
| according to any cyclic algorithm with a cycle length >> n(X) (let's say of
| length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you
| can show that you will find a first non-colliding value S(c) in a
| computationally small number of iterations (the expected number of
| iterations c is in essence 1, assuming n(X)<<2^H).
All I need to do, is pick a name, any name, N, that exists in my zone,
and then for each potential S calculate HASH(N, S[i], H) and add that
name to my zone file. Now for name N, there's no possible S which doesn't
generate a conflict.
How practical this is depends upon how big the range of possible salts is,
but practical or not, it is clearly possible. The number of bits in the
hash function is immaterial here (though as it gets bigger, the number of
possible salts must get less, as the total label length is limited).
| For the record, for the reasons Ben mentioned a good while ago, I am not
| sure why collisions are actually a problem at all
This one is a different issue, and isn't one I was addressing (just the
theory that it is possible to go about stealing names from the namespace
without ever doing any harm).
The usual problems (if the RRtype of the clashing name is NS or CNAME)
might not apply to NSEC because of the weird rules that (I think) apply
to this new record type (or then again they may, I'm no expert on the
DNSSEC RR types).
But I'd want to know just how they effect wildcards. If I have a
* IN MX 10 foobar.
record in my zone file (for the example. zone), I expect that anyone looking
up any-random-hash.example. is going to get the foobar MX record, just like
anyone looking up any other name that doesn't exist will get. If the
NSEC records existing mean that the the wildcard doesn't get found, then
things are badly broken. To fix that I'd have to add explicit MX records
for every hash label (and a *.hash-label as well) which would alter the
set of NSEC records that has to exist (clearly adding more), which means more
MX records required, and ... (so it isn't really fixable). That is, unless
NSEC records are to be treated as "special" for wildcard purposes.
kre
Simon Josefsson
> Date: Fri, 10 Sep 2004 20:50:58 +0200
> From: Simon Josefsson <j...@extundo.com>
> Message-ID: <ilusm9q...@latte.josefsson.org>
>
> | There are at least two solutions to that problem.
>
> no, there are no solutions for this problem in any proposal that requires
> adding new names (attempts to steal some of the namespace) for any existing
> RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're
> relevant only to SRV lookups and don't prevent _tcp being used as a label
> for any other RR types).
Here's an idea to add another level of indirection to handle this:
jim.foo. IN A
alex.jim.foo. IN CNAME ...
foo. IN NSECBISZONE _nix
alex._nix.foo. IN NSECbis ....
In other words, the part of the namespace that is stolen for NSECbis
records can be chosen to avoid existing names.
I'd agree with anyone who thinks this is complex. I don't believe
stealing a part of the namespace for technical reasons, much like SRV
does, is a problem.
> | The first is to use salting to make sure there are no collisions.
>
> That doesn't work, you just collide with a different name. For any
> name that you propose adding, I simply add the same name with whatever
> RR types cause your proposal to have problems.
Then I'll change the salt, to get another non-colliding name. I agree
with Alex Bligh's discussion. Remember, you don't get to add new
names after NSECbis records have been added. The NSECbis tool have
the entire zone content, and can chose salt values to make sure there
are no collisions.
However, I have not been convinced that salting is necessary in the
first place, since I don't consider colliding names a realistic
problem. Same for offline dictionary attacks against the hash
function.
> | The second one is to place the NSECbis record in a separate name
> | space.
>
> In this case the "separate name space" is the name that is the problem.
I want to understand why. Please explain. What is the problem?
Thanks,
Simon
Alex Bligh
--On 11 September 2004 03:59 +0700 Robert Elz <k...@munnari.OZ.AU> wrote:
> | The first is to use salting to make sure there are no collisions.
>
> That doesn't work, you just collide with a different name. For any
> name that you propose adding, I simply add the same name with whatever
> RR types cause your proposal to have problems.
[ I hope Olaf's going to forgive me on this one, but I think we are
now talking about something quite different from the circular
discussion on whether or not non-enumerability is needed and
what the requirements are so I have changed the subject appropriately ]
I'm lost. Let me do some CS/Math and then see if I have applied it
without missing the point:
If you have a set of labels X, and a set of labels Y where
Y(i) = HASH ( X(i) , S, H)
i.e. a hash of X(i) using salt S (the same for all values of i) and H bit
hash, then, providing n(X) << 2^H, it's trivially easy (and computationally
efficient) to find a value S such that there are NO values i, j such that
Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that
there are no collisions between the range and domain of the hash function.
One possible mechanism is simply to iterate through values of S chosen
according to any cyclic algorithm with a cycle length >> n(X) (let's say of
length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you
can show that you will find a first non-colliding value S(c) in a
computationally small number of iterations (the expected number of
iterations c is in essence 1, assuming n(X)<<2^H).
I don't *think* I'm wrong on that bit of CS / math.
Assuming I'm not wrong, and assuming some NSEC2/NSEC+-esque proposal,
whatever routine is used to generate the NSEC2/NSEC+ etc. records you don't
want to collide (let's say, to be really safe, with ANY record, no matter
WHAT the RRTYPE) you just first create them with S(1), if there is a
collision (irrespective of RRTYPE) try S(2), etc. etc., and again the
expected number of iterations is in essence 1, assuming n(X)<<2^H.
Now if you add another name, you do the same. Is there a collision now? No
- then no problem. Yes - then time to resalt. There's no external DoS risk
as it's only the zone owner who can add the names - if they are
deliberately (for some reason) chosing to add names that collide with
existing hashed records, then "don't do that".
So I think they CAN be avoided algorithmically - in a similar sort
of way to the creation of Bloom filters, but with far less computational
complexity.
For the record, for the reasons Ben mentioned a good while ago, I am not
sure why collisions are actually a problem at all - i.e. if we have
$ORIGIN example.com
alex IN TXT "1"
jim IN TXT "2"
why is it a problem if HASH("alex")="jim" and so we also have
jim IN NSECBLAH whatever
I'm quite prepared to believe it is a problem, and my understanding
of the protocol is flawed, but I'd like to be educated :-)
Alex
Edward Lewis
>Perhaps, but if people keep not understanding, there's little choice but
>to keep on repeating. Eventually the message might get through.
Or maybe trying to explain in a different manner. Perhaps one's
words are being read within the same context that they are being
written. ;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
"I can't go to Miami. I'm expecting calls from telemarketers." -
Grandpa Simpson.
Samuel Weiler
> Another potential problem with the current hashing proposals is that a
> hash could collide with a label for an existing name. ie Suppose the
> hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo
> already exists as a delegation point or CNAME.
Apologies if this has been mentioned before[1], but I couldn't find it
in this thread, and it came up in a discussion yesterday...
The way I understand the proposals on the table, this sort of
collision is fine and dandy. No "real" name should "naturally" have
an NSEC++. If another "real" name happens to hash to another existing
name, you insert the NSEC++ there as normal. The pre-existing "real"
name has it's corresponding NSEC at some (presumably different) name.
Example:
"real" names:
example.com SOA/DNSKEY/etc. (the apex)
a.example.com A 127.0.0.1
overly-long-name.example.com A 10.1.1.1
Hash all three:
hash(apex) ---> qwertyuiop\034\011zyxw
hash(a) ---> overly-long-name
hash(overly-long-name) ---> acbdefghijklmnoz\000\009
And add these three NSEC++ RR's when signing [1]:
acbdefghijklmnoz\000\009 NSEC++ qwertyuiop\034\011zyxw A
qwertyuiop\034\011zyxw NSEC++ overly-long-name SOA DNSKEY NS
overly-long-name NSEC++ acbdefghijklmnoz\000\009 A
If anyone every queries for (overly-long-name,IN,MX), they get the
acbdefghijklmnoz\000\009 NSEC++ record.
So there's no conflict between having "real" RRsets and generated
NSEC++'s at the same name.
-- Sam
[1] The type bitmaps in these aren't quite right; they omit RRSIG and
NSEC++.