Subject: [ietf-dkim] Threats Issue - Large DNS records make servers targets for spoofed source amplification attacks abuse

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Feb 2006 07:45:41 -0800 (PST)

There have been a lot of discussions going on in the last few days
at NANOG and other dns operations lists that are related to issue of
public recursive dns servers being used to amplify an attacks:
  http://www.gossamer-threads.com/lists/nanog/users/89657
  http://lists.oarci.net/pipermail/dns-operations/2006-February/thread.html

The general description of the problem is that bad guys are sending
spoofed udp packets to servers in a way so that the servers would send 
data (to spoofed source) that is considerably larger then the original 
request - thus the amplification. For more information, you may want
to read http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf

In current case with DNS abuse documented above, most (almost all)
dns servers only have records that a small and so the servers are not
good targets for any significant amplification. So attackers are
basically poisoning recursive nameservers with their own large data
as a way to get them to become good targets and good amplifiers - this
has been quite successful and is currently major issue for dns operations 
and security folks.

Getting back to this group work - you are expecting to introduce large
DNS records as a mainstream for many dns servers. This would make such
servers a great target for use in amplification attacks even if those
servers are not configured to do recursion. This is bad and potential
for such an attack and abuse for anyone using DKIM must be documented
and it must be made clear that servers with DKIM records may become
targets for use in DNS amplification attacks. In fact the larger the
record you put in dns, the better target for such an attack it becomes!

Note that there is currently no good solution to this issue for UDP 
protocols (most either do TCP-like session establishment before sending
large data or they are engineered so that responses can be limited with
ACLs to only specified group of systems, i.e. local LAN in case of DHCP).
My personal view is that if there is a way to avoid introducing large 
records into UDP one query-response situation, that it absolutely must be 
done. So I would see as best solution a replacement of public keys in dns 
with an approach that uses a lot smaller fingerprints in DNS.

-- 
William Leibzon
Elan Networks
[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Feb 2006 16:31:04 -0800

> record you put in dns, the better target for such an attack it becomes!
If we were to include this in the threat document, it would need to go
into a new category because it's not a threat to the signature mechanism
nor to SSP, but rather an attack on DNS that might be facilitated by
DKIM.  I'm not sure whether this is in-scope for the threat document or
not, but it would be an expansion of its current scope to include it.
> records into UDP one query-response situation, that it absolutely must
> be done. So I would see as best solution a replacement of public keys
> in dns with an approach that uses a lot smaller fingerprints in DNS.
I haven't been following any discussion on this problem, but wouldn't it
also be a problem for DNSSEC?  I don't think that, even if DKIM records
were to be smaller, the overall DNS situation would be that much better.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Feb 2006 16:50:35 -0800

On Feb 27, 2006, at 4:31 PM, Jim Fenton wrote:

>> In fact the larger the record you put in dns, the better target  
>> for such an attack it becomes!
>
> If we were to include this in the threat document, it would need to  
> go into a new category because it's not a threat to the signature  
> mechanism nor to SSP, but rather an attack on DNS that might be  
> facilitated by DKIM.  I'm not sure whether this is in-scope for the  
> threat document or not, but it would be an expansion of its current  
> scope to include it.

A concern related to DKIM would be to ensure DNS UDP payloads are not  
exceeded by the key record response.  Not exposing recursive DNS  
servers is simply good practices which are not specifically related  
to DKIM.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Feb 2006 20:17:08 -0800 (PST)

> not, but it would be an expansion of its current scope to include it.

It is definitely something that people considering DKIM should be aware
of so it should be in threats documents and if you think you need new 
category - do it. Part of this problem is directly threat to DKIM (as 
opposed to threat because of DKIM) as such abuse of DKIM public key 
records would result in denial of service attack on dns server serving
the records and thus denial of service on DKIM verification process. But 
this is rather one of the after-effects then a source of the problem.

> were to be smaller, the overall DNS situation would be that much better.

I'm trying to research this very case as I've not had enough time 
to follow DNSSEC as well (it continued to be somewhat fluid too).
I believe it might be beneficial to have DNS advisor and have him/her
go into the details and consider these issues, but as we do have multiple 
focused groups in IETF, I'll ask the questions on namedroppers and/or dns 
operations mail list.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Feb 2006 22:34:06 -0800

william(at)elan.net wrote:
> It is definitely something that people considering DKIM should be
> aware of so it should be in threats documents and if you think you
> need new category - do it. Part of this problem is directly threat to
> DKIM (as opposed to threat because of DKIM) as such abuse of DKIM
> public key records would result in denial of service attack on dns
> server serving the records and thus denial of service on DKIM
> verification process. But this is rather one of the after-effects then
> a source of the problem.
That's one vote in favor of including this sort of threat in the threats
document.  Other opinions?

-Jim

---

From: [email-masked]
Date: Tue, 28 Feb 2006 08:49:12 -0000 (GMT)

> document.  Other opinions?

Including this sounds reasonable. It'd sound even more reasonable
if someone wrote it up in a paragraph suited for inclusion in the
document.

Stephen.