On Mon, 27 Feb 2006, Jim Fenton wrote:
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!
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.
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.
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.
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.
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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html