Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review

[Amir Herzberg <[e-mail]>]

On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <[e-mail]> 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.

-- 
Amir Herzberg
Associate Professor, Dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com