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

[Amir Herzberg <[e-mail]>]

Doug, thanks! I completely agree that applying SPF at the client - or in
fact, anywhere after the border MTA - is probably a very poor idea, due to
the potential exposure to DoS and DNS poisoning exploits. I just didn't
think this people would do it - I'll try to add warning against it. This is
far beyond the question of whether there is also some real goal in doing SPF
validation at this point (client) [referring to Chris's note].

And I agree that it may be worthwhile also mentioning the 10*10
amplification factor for implementations that allow 10 mechanisms where each
could do 10 MX (or PTR) RR lookups, for a total of 100 DNS queries (or I
think actually 111). Notice that again, the use of SPF by multiple mail
agents, e.g. at the client, would provide even further amplification.

Amir

On Tue, May 26, 2009 at 4:23 AM, Douglas Otis <[e-mail]> wrote:

>
> On May 25, 2009, at 1:45 PM, Amir Herzberg wrote:
>
>  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 can be found in ClamAV, SpamAssassin, etc. extend filtering of incoming
> email at the desktop for any type of MUA.  There are even Thunderbird
> plugins that specifically provide SPF resolution.
>
>  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.
>>
>
> A common mistake.
>
>  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.
>>
>
> When the goal is to poison DNS, the SPF specifications limit resolution to
> 10 mechanisms, and then the resolution of MX records (one such mechanism) to
> 10. 10 x 10 = 100.  The draft that I wrote long ago demonstrated 100
> transactions using unmodified off-the-shelf SPF libraries.
>
>  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.
>>
>
> You might want to go through the numbers.  When SPF records are being
> cached, but then expanded upon using macros, the cost to the attacker
> becomes nil, however the impact on their victim can profound.
>
>
> -Doug
>
> _______________________________________________
> Asrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/asrg
>



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