Subject: Re: [dnsext] Hardening DNS using existing protocol elements

From: Nicholas Weaver <[email-masked]>
Date: Thu, 11 Jun 2009 05:56:35 -0700

On Jun 10, 2009, at 11:33 PM, George Barwood wrote:

> It seems to me that there are 3 problems to be solved:
>
> (1) Out-of-path attacks against the 16 bit DNS ID field.
>
> Solution: EDNS Ping ( which I would like to see renamed EDNS  
> Extended ID ).
> That is, the client includes an OPT record that the server copies  
> into it's response.
>
> (2) Out-of-path attacks against IP fragments.
>
> Solution: Response is encrypted* in an OPT record, using the  
> Extended ID as the key,
> if response is > 512 bytes and client indicates support ( by means  
> of an OPT flag ).

NO!  If we want to go down the road at all, they should have the same  
mechanism for 1 and 2:

If there is an EDNS record saying "paranoid", that value should have a  
64b NONCE:

The reply should REPLACE the EDNS extended ID with HMAC-SHA256  
(truncated to 64b) of the entire message.

This is what hashes and HMAC are for.

But to my mind, I really don't think its worth bothering.

Lets face it, who's picking on even all the lAme non-randomizing DNS  
resolvers out there?

Heck, who's picking on the DNS resolvers that don't do bailywick  
checking right?

> (3) Amplification attacks against authoritative servers.
>
> Solution: An OPT record sent by the server asking the client to  
> prove their IP address
> is not forged, if server is under attack, the response is large and  
> the client indicates
> support ( by means of an OPT flag ). The client repeats the request,  
> including a copy
> of the OPT record. Clients that do not indicate support may instead  
> get SERVFAIL
> from a server that is under attack, so they have a big incentive to  
> upgrade.

Bah.  You can just wash that attack through recursive resolvers which  
accept external requests, and distribute things so much.

--
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: Nicholas Weaver <[email-masked]>
Date: Thu, 11 Jun 2009 07:11:38 -0700

On Jun 11, 2009, at 6:56 AM, George Barwood wrote:
> What has bailywick checking got to do with it?
> We are talking about blind attacks modifying fragmented IP packets  
> ( very easy to do ).
> For a resolver behind a NAT that means a single forged packet.

Because there are horribly broken DNS resolvers out there which will  
happily accept pretty much anything in a glue record.

Those you don't need packet injection at ALL to poison.

> Don't understand you.
> Are you saying that amplification attacks against DNSSEC authorities  
> are not a problem?
> Or that there are other attacks that are worse?

That you don't need to target DNSSEC authorities, but can use  
recursive resolvers, and since there are soooo many of those, rate  
limiting doesn't really matter or help.

> George

---

From: Florian Weimer <[email-masked]>
Date: Thu, 11 Jun 2009 16:26:00 +0200

> What has bailywick checking got to do with it?

Lack of attacks means that it's difficult to justify work on
countermeasures.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 11 Jun 2009 08:18:50 -0700

On Jun 11, 2009, at 7:32 AM, George Barwood wrote:
>
> That's from the attackers point of view.
> From my point of view, I want a secure cache.
> I don't want an out-of-path attacker to be able to easily re-route  
> or sample
> my DNS traffic, for example ( we are not just talking DoS ).

If this is your objective, then you want the following, even behind a  
NAT:

Run your OWN recursive resolver, with 0x20 enabled, EDNS DISABLED, and  
the "No race until win" glue policies. EG, unbound:

The 0x20 means that you have about +9-12b of entropy for real world  
names

The paranoid glue policy means that the kaminski attack against 0x20  
doesn't work (eg, 1111.com can only work to poison 1111.com's record,  
not the nameserver record for .com).

By not having EDNS, you keep the buffer size small so you don't have  
fragmentation issues.

And by running your own resolver, you are too small a target to bother  
with.

---

From: Stefan Schmidt <[email-masked]>
Date: Thu, 11 Jun 2009 17:28:55 +0200

> >> Heck, who's picking on the DNS resolvers that don't do bailywick  

The DNS 'community'.

> Lack of attacks means that it's difficult to justify work on

IIRC the argument most commonly used in the discussion to speed up DNSSEC
'deployment' is that in its current state DNS is prone to Kaminsky-style
attacks. I surely hope you still find justification to work on protecting DNS
from this kind of attack because in my world good engineering stands for
thinking ahead of these things.

	Stefan

---

From: [email-masked]
Date: Thu, 11 Jun 2009 17:25:42 +0100

> I'm fully aware I must not enable EDNS.
> 
> But now I want to start deploying DNSSEC. I still want security 
> against out-of-path attacks for unsigned zones.

If your upstream recursive resolver is a recent(ish) version of BIND (or 
Unbound?) with DNSSEC enabled without EDNS0 then you can get some security 
by setting AD=1 in your queries.

You'll not get any DNSSEC related RRs in your answers so your buffer size 
problems are no worse than now.

You will get AD=1 responses for good zones, AD=0 for insecured zones, and 
SERVFAIL for bogus zones.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jun 2009 06:50:22 +0900

> attacks.

DNSSEC is also prone to Kaminsky-stype attacks.

If you have one time access to signature generation mechanism
of a zone, you can get a valid signature over false data.
The attack is new to DNSSEC easier than modifying zone content
and is hardly noticable.

With the signature and the data, attacking of DNSSEC is
trivially easy.

The solution is not to deploy DNSSEC but to protect cache
abandoning the broken concept of bailiwick.

						Masataka Ohta