On Mon, May 25, 2009 at 6:54 PM, Douglas Otis
<dotis at mail-abuse.org> wrote:
http://amir.herzberg.googlepages.com/somerecentpapers
This paper refers to DNS poisoning without fully exploring how SPF might be used to enable DNS poisoning. SPF might be checked by MUAs in some cases. More than just resolvers associated with MTAs are affected, so separate resolvers for MTAs, which themselves might become poisoned, does not represent a good solution.
Sorry - I simply was not aware of SPF checks being invoked by MUAs. I actually find it a bit strange that MUAs would do SPF validations, considering they don't get MAIL FROM, but human ingenuity is endless and I apologize for this ignorance. Doug, can you give me specific examples - preferably of common MUA clients and if possible, of appropriate documentation so I can read about it and/or test it? Tks!
SPF provides bad actors access to DNS resolvers that might otherwise be protected by ACLs. At today's Internet speeds, DNS transactional IDs do not represent adequate protection. SPF's use of macros ignores this security venerability. Suggesting the use of DNSSEC is not reasonable justification for ignoring this problem.
I believe my text already makes this argument except for considering the issue limited to MTAs, MDAs.
SPF supports the use of macros to access A, AAAA, PTR and TXT DNS resource records. These macros might expand local-parts within the email-message, which means SPF records may NOT be fully cacheable. Subsequent record resolutions can be triggered by the SPF macros, where as may as one hundred such record resolutions can occur when resolving a single SMTP source authorization.
But spec says (and even if it didn't, common sense would) that a reasonable limit of resolutions, say 10, should be used. I think I even discussed this, I definitely considered discussing this.
These subsequent resolution events can be directed toward both a DNS resolver under the control of the bad actor to obtain timing and target information for the remaining tens or hundreds of record resolutions made against their victim's caching resolvers. This attack can be renewed by simply changing local-parts within either the bounce address or the PRA. Perhaps both the bounce address and the PRA authorization verifications are attempted, which would have the effect of doubling the amount of traffic.
This is indeed the attack I've sketched in the paper; do u think more details were needed? Maybe I can simply add citation of some detailed publication on this since I think adding much more details is not reasonable for such a review.
Associate Professor, Dept. of Computer Science