Subject: Re: WG Last Call: DNSSEC bis documents

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2004 15:54:17 +0000 (UTC)

Olaf M. Kolkman <olaf <at> ripe.net> writes:

> This message starts the WG last call for the DNSSEC-bis document set.
> 
>    draft-ietf-dnsext-dnssec-intro-10.txt 

Quoting the security considerations:

   DNSSEC introduces the ability for a hostile party to enumerate all
   the names in a zone by following the NSEC chain. NSEC RRs assert
   which names do not exist in a zone by linking from existing name to
   existing name along a canonical ordering of all the names within a
   zone. Thus, an attacker can query these NSEC RRs in sequence to
   obtain all the names in a zone. While not an attack on the DNS
   itself, this could allow an attacker to map network hosts or other
   resources by enumerating the contents of a zone. There are non-DNS
   protocol means of detecting and limiting this attack beyond the scope
   of this document set.

What are those "non-DNS protocol means of detecting and limiting the attack"?

I believe there are no viable means to prevent the attack in reasonable
scenarios where DNSSEC is used on the public Internet.  If my assessment is
correct, I don't think there should be text implying the problem can be taken
care of by non-DNS means.

If the statement refer to rate limiting and/or counting the number of queries
from a certain IP, that is so trivially defeated that I doubt that anyone will
go thru the trouble of implementing those precautions for NSEC abuse alone.  It
may generate more problems than it solve: false positives in the detection logic
may disable DNSSEC functionality at end nodes.  If the text refer to those
precautions, and the text is kept, in fairness a warning that the precaution may
cause failures should be added.

I believe it would be more honest to simply state that DNSSEC introduce this
security vulnerability, full stop.  I.e., drop the last sentence.

Thanks,
Simon

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

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 May 2004 19:07:44 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >>    DNSSEC introduces the ability for a hostile party to
    >> enumerate all the names in a zone by following the NSEC
    >> chain. NSEC RRs assert which names do not exist in a zone
    >> by linking from existing name to existing name along a
    >> canonical ordering of all the names within a zone. Thus, an
    >> attacker can query these NSEC RRs in sequence to obtain all
    >> the names in a zone. While not an attack on the DNS itself,
    >> this could allow an attacker to map network hosts or other
    >> resources by enumerating the contents of a zone. There are
    >> non-DNS protocol means of detecting and limiting this
    >> attack beyond the scope of this document set.

    Simon> I believe there are no viable means to prevent the attack
    Simon> in reasonable scenarios where DNSSEC is used on the public
    Simon> Internet.  If my assessment is correct, I don't think there
    Simon> should be text implying the problem can be taken care of by
    Simon> non-DNS means.

The original text should stand IMO.

Rate limiting and intelligent firewall filtering can reduce the
exposure to NSEC traversal. It should be fairly straightforward to
train a name server implementation to detect these attacks too. Sure,
these defences might not be much help against a well-disguised
attack. But they do provide some level of protection. So there are
some non-DNS means of detecting and limiting NSEC traversals that are
outwith the scope of the draft.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 May 2004 19:38:23 +0100

> outwith the scope of the draft.

I believe experience tells us that the people interested in these 
attacks are highly capable of disguising them well.

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

---

From: "Simon Josefsson" <[email-masked]>
Date: Wed, 19 May 2004 11:50:47 +0200 (CEST)

> outwith the scope of the draft.

Then inform the reader that any precautions do not remove the need to
worry about the issue, and any such precautions introduce new
denial-of-service considerations.  Just consider sending spoofed DNS
requests from a certain IP address, to trigger the NSEC traversal
detection logic, to disable DNSSEC functionality for a specific host.  The
host could be a DNS cache for a big ISP, thereby disabling DNSSEC
functionality for many users.

The last sentence of the current paragraph imply the problem can be
sufficiently solved by non-DNS means, and I have seen no indication that
this is true in general.

Until a solution has been fleshed out, I continue to believe that removing
the last sentence, that refer to experimental and incomplete precautions,
would be preferrable.  Second to that, I'd suggest appending the following
text, to give the reader some perspective on the effectiveness of those
non-DNS means:

   Note that these non-DNS means do not remove the need to worry about
   this issue, as at least the currently proposed precautions are trivially
   defeated.  Further, they may introduce new denial of service
   considerations, where an attacker may disable DNSSEC functionality
   for a specific host, or a set of hosts behind a specific DNS cache.

Thanks,
Simon

---

From: David Blacka <[email-masked]>
Date: Wed, 19 May 2004 10:22:55 -0400

> What are those "non-DNS protocol means of detecting and limiting the
...
> I believe it would be more honest to simply state that DNSSEC introduce
> this security vulnerability, full stop.  I.e., drop the last sentence.

I, too, would like to see this last sentence dropped, because this sentence 
provides no useful information.

There may or may not be non-DNS means of limiting NSEC walking, but simply 
stating that they exist somewhere out there in the wide, wide world without 
providing a pointer to any of them is not helpful to the reader.

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 19:01:04 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Right.  But designing DNSSEC to not introduce new realistic
    Simon> attack vectors, compared to vanilla DNS, has always
    Simon> appeared sensible to me.  Whois is one example of where the
    Simon> new attack vector can be utilized.  Improving the whois
    Simon> protocol will remove whois as an example for our
    Simon> discussions, but it will not remove the traversal problem.

While this is true, I'm not convinced that there really is a traversal
problem. The DNS is a public database after all. Of course some people
restrict zone transfers for operational and policy reasons, notably
TLDs. But these are not protocol issues. And while it would be nice if
DNSSEC didn't make zone traversal easy -- like your now dead NO record
draft tried to do -- it's so far been too hard to find a way of doing
that which works for all possibilities for authenticated proof of
non-existence. If there weren't so many tricky corner cases,
especially with wildcards, no doubt something like your NO record
would have been incorporated into the current drafts.

I think we're at a point with DNSSEC where an engineering decision
needs to be made. The question shouldn't be whether DNSSEC is perfect
or not but if DNSSEC is "good enough".

    Simon> The alternatives to NSEC do reduce the attack vector into
    Simon> an offline dictionary attack, which I believe is an
    Simon> acceptable risk.

If the rewards for a successful attack are high enough, this isn't an
acceptable risk. How much would it cost to implement SHA-1 in
hardware, assuming there aren't chips that can do this already?

---

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

> problem. The DNS is a public database after all. Of course some people

Jim, you know I'm all with you here and I've been arguing for years that AXFR
restrictions are not a security but an obscurity measure.

> restrict zone transfers for operational and policy reasons, notably

They've done it due to BIND (and other products) introducing the ability
and due to "security consultants" recommending it and for other non-reasons.
If it were only for those I'd say: go, do your homework.
But as always, some animals are more equal than others and in this case
they have a point. Being able to list all registered/delegated names is
different from serving a name upon request. And while we seem to agree that
the data is public, the compilation may not.

> TLDs. But these are not protocol issues. And while it would be nice if

Well, you're right, the DNS wasn't built to keep things secret but instead
to publish data. But now we have a "feature" that has been an (unspoken)
part of the system for years, which has a value for a limited but important
set of zones and it's going to go away.

> or not but if DNSSEC is "good enough".

The problem is that the engineering question is closely coupled to an
operational or maybe even policy question for a key part of the infrastructure.
If DNSSEC isn't "good enough" for TLD zones (or a significant subset of those),
that's a show stopper. Yes, we could have had this discussion earlier.

> hardware, assuming there aren't chips that can do this already?

There are other alternatives, including online signing, maybe with a
different key. The zones in question have some special properties (almost
"NS only"), which may also be exploited to find a solution.

-Peter

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 May 2004 22:52:22 +0000 (UTC)

Jim Reid <jim <at> rfc1035.com> writes:

> And while it would be nice if DNSSEC didn't make zone traversal
> easy -- like your now dead NO record draft tried to do -- it's
> so far been too hard to find a way of doing that which works for
> all possibilities for authenticated proof of non-existence. If
> there weren't so many tricky corner cases, especially with
> wildcards, no doubt something like your NO record would have
> been incorporated into the current drafts.

What was wrong with the wildcard handling in the expired NO draft?  I
don't recall pending technical issues last time.  Anyway, solving
wildcard handling is a simple technical matter, despite its
complexities.  I haven't seen anyone seriously suggesting it is
strictly impossible to solve it.

> hardware, assuming there aren't chips that can do this already?

My point was that nobody would bother to do dictionary attacks on
SHA-1 hashes when they can do online dictionary attacks more easily.
And online dictionary attacks cannot be prevented currently.  So the
attack has been mitigated beyond other currently acceptably attack
vectors.

Regards,
Simon

---

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

> ...
> The verifier is able to discover that one out of all relevant wildcard
> situations apply, in this case the third of your clause.  To do this
> it simply iterates over all possible candidates (a small number). ...

it is not reasonable to ask a verifier to iterate in this additional way.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 May 2004 09:30:46 +0200

> it is not reasonable to ask a verifier to iterate in this additional way.

Why not?

Are you worried about CPU efficiency?  The most computationally
expensive operation of the iteration is likely the hashing.  I don't
see anything else in the verification process that would take time;
the iteration over possible relevant names is over a small number,
typically <<100, and each loop compute a hash and can directly compare
the hash against the received NO/NSEC2 records.  You could cache some
of the hash computations to improve performance, but given the below I
doubt you would need that for performance reasons alone.

My box does ~1.000.000 SHA1 ops/second, compared to ~1.000 RSA 512 bit
verify ops/second, and ~200 RSA 1024 bit verify ops/second.

So it doesn't appear as CPU efficiency would be a valid concern.

Code complexity?  The logic is straight forward.  You can modularize
the NO/NSEC2 wildcard verify logic into a separate module.  It is just
a Small Matter Of Programming.  Compared to other warts in NXT/NSEC,
it doesn't have any consequences on the basic DNS model.  Take the
zone cut issue with NXT/NSEC, where you have two records with the same
name/type/class, but must not confuse the two as one comes from the
parent zone and one from the child zone.  Catering for this wart may
require changes to the backend of a DNS cache.  Recall that NO (and
likely also NSEC2, but I haven't read it) fixes the zone cut issue.

Regards,
Simon

---

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

> > it is not reasonable to ask a verifier to iterate in this additional way.

because it's already iterating in several other ways, and this is basically
a new innermost-loop, and the span of the iteration can be controlled by an
attacker.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 May 2004 02:06:52 +0200

> a new innermost-loop, and the span of the iteration can be controlled by an

The maximum iteration count needed can be computed from the domain
name used in the query (e.g., a.b.c.d.e.f.com), so the attacker cannot
influence the iteration count by returning special data.

An attacker may cause clients to look up a name chosen by the
attacker, perhaps as the worst case a.b.c.d.e.f.g.h.....z.com or
similar.  But the attacker is limited by the limits in the DNS
protocol -- owner names cannot be longer than 255 octets.  So the
attacker can cause the client to compute a few hundred SHA-1 hashes,
in the worst case.

A few hundred SHA-1 hashes is fast compared to a 2048 bit RSA verify.
And making a client perform a 2048 bit RSA verify is possible today,
just send it an bogus KEY/SIG pair.

Regards,
Simon

---

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

> I'm sorry to be dense, but I don't follow how NO didn't work.  ...
> Don't get me wrong, I'm not trying to push a NO solution ...

and yet, you must.  perhaps that's the component i'm seeing that others
here are not.  if we're going to reopen the dnssec design, then we have
to re-evaluate NO, opt-in, as well as NSEC2, and anything else lurking
in the shadows.  anything we don't evaluate fully enough, will clearly
just become an 11th hour showstopped 18 months from now when we next feel
ready to start deployment.  therefore, if this WG decides to adopt NSEC2,
we have to broaden the net to include competing proposals, some of whom
were shot down just because of the lateness of the hour rather than for
functional reasons.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 May 2004 21:00:58 +0200

> were shot down just because of the lateness of the hour rather than for

I agree with all that.  I don't mind of others wants to reconsider the
NO proposal, and time permitting I can try to assist.  But my only
goal now has been to improve the current specifications, so they can
be shipped (if that is the consensus), by dropping a misleading
statement in the security consideration.  Those two matters are
orthogonal, and quite different in proportions.  I haven't asked for a
redesign, and I'm indifferent to whether one is needed.

Regards,
Simon

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 May 2004 16:37:10 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Well spoken, I couldn't agree more.  I find it puzzling
    Simon> that some TLDs, even those stating they have no problem
    Simon> with NXT/NSEC walking, have been restricting zone access.

Why? There are perfectly good operational reasons for that. Like not
wanting their name servers burdened with large numbers of long-lived
TCP connections. Some may even be running DNS software that doesn't
*implement* AXFR.

    Simon> Perhaps this WG should simply acknowledge that
    Simon> organizations running TLDs will never agree on policy
    Simon> issues.

Apart from the obvious universal truths, that's a given. Around the
world there are too many different (mutually exclusive?) laws on stuff
like data protection, privacy, crypto, consumer protection, monopolies
and so on. Reconciling these is impossible. It would be foolish to
even try.