william(at)elan.net 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.
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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html