Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt

From: [email-masked]
Date: Tue, 06 Apr 2004 10:31:11 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Threat Analysis Of The Domain Name System
	Author(s)	: D. Atkins, R. Austein
	Filename	: draft-ietf-dnsext-dns-threats-07.txt
	Pages		: 16
	Date		: 2004-4-5
	
Although the DNS Security Extensions (DNSSEC) have been under
   development for most of the last decade, the IETF has never written
   down the specific set of threats against which DNSSEC is designed to
   protect.  Among other drawbacks, this cart-before-the-horse situation
   has made it difficult to determine whether DNSSEC meets its design
   goals, since its design goals are not well specified.  This note
   attempts to document some of the known threats to the DNS, and, in
   doing so, attempts to measure to what extent (if any) DNSSEC is a
   useful tool in defending against these threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dns-threats-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dns-threats-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Apr 2004 12:47:48 -0400

For those who have not been following the exciting details in the
draft tracker: this is the final version of this draft, which
addresses the last of the issues that came up during IETF last call
and IESG review.  As far as the authors know, we are done, and we
expect formal IESG publication approval within a few days.

We don't think any of the recent changes are controversial, but:

a) If anyone thinks there's a show-stopping problem with the changes,
   speak up now;

b) No new issues, please, it's past time to ship this puppy.

Change logs available at http://www.hactrn.net/ietf/dns/threats/

--Rob and Derek

--
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: Masataka Ohta <[email-masked]>
Date: Wed, 07 Apr 2004 20:16:20 +0900

> expect formal IESG publication approval within a few days.

Can someone explain why "Name Chaining attacks" are
harmful?

As far as I understand, name chaining is, first, to let
the victim access a name of attackers choice and, secondly,
to let the victim access names of attackers choice.

So, if the attacker can control the first name, why it
is more harmful that the attacker can control the
subsequent accesses?

If the attacker can control the first name and the victim
is not protected from cache poisoning, the attacker can
inject a lot of false information with the first access
that I can see no point of chaining.

					Masataka Ohta

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 7 Apr 2004 14:36:25 -0400

I think the new version is good.  From my reading of the draft "name
chaining" sounds like a slightly better term for that class of attacks.

I do not see any show-stopper problems.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rob Austein
> Sent: Tuesday, April 06, 2004 12:48 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt
>
>

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Apr 2004 19:51:44 -0400

At Wed, 07 Apr 2004 20:16:20 +0900, Masataka Ohta wrote:
> 
> Can someone explain why "Name Chaining attacks" are harmful?
> 
> As far as I understand, name chaining is, first, to let the victim
> access a name of attackers choice and, secondly, to let the victim
> access names of attackers choice.
> 
> So, if the attacker can control the first name, why it is more
> harmful that the attacker can control the subsequent accesses?
> 
> If the attacker can control the first name and the victim is not
> protected from cache poisoning, the attacker can inject a lot of
> false information with the first access that I can see no point of
> chaining.

Relevance checks can protect against many forms of name-based attacks,
but not against name-chaining attacks.

Eg, pretend (for purposes of discussion, no insult intended) that
you're silly enough to run an HTML-vulnerable MUA, an attacker sends
you a web bug linking to http://very.evil.example, and your MUA duely
generates a query for very.evil.example.  If the name server for
evil.example replies to your query for very.evil.example by telling
you that important.example.org is at some random IP address
(presumably controlled by the attacker), your resolver's relevance
checks will reject this response because an answer about
important.example.org isn't relevant to a query for very.evil.example.

If, however, the name server for evil.example tells you that
very.evil.example is served by important.example.org and oh, by the
way, here's the address of important.example.org, your resolver will
think that the address of important.example.org is relevant, will
probably believe it, and will probably cache it.  Oops.  There are
other variants (eg, long CNAME chains), but that's the basic idea.

The important characteristic of this class of attacks is that they
allow the attacker to introduce a new name into the protocol exchange
as a side effect of what looks like a normal protocol operation.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 12 Apr 2004 06:56:02 +0900

Rob Austein;

Thank you for the explanation.

> but not against name-chaining attacks.

That is a result of improper relevance checks, I think.

The only meaningful relevance check MUST be (save that for
glues) that the names are at or below the zone served by
the current server, which is not affected by chaining.

If implementations are doing otherwise, they are poor, I
believe.

> probably believe it, and will probably cache it.

For a glue, it is necessary to check the dereference point is
at or below the zone of the current server and to tag the cache
entry of glues with the corresponding dereference points so
that the entries are not used for other purposes (normal As or
glue As of other dereferences).

> There are other variants (eg, long CNAME chains), but that's
> the basic idea.

It should also be noted that RFC 1035 says:

	CNAME RRs cause no additional section processing

though it is not prohibitted.

> as a side effect of what looks like a normal protocol operation.

So, I think the threat is essentially that of redirection,
protection against which automatically protects against
chaining.

						Masataka Ohta