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
