ietf-asrg
[Top] [All Lists]

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

2009-05-27 01:59:41
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 <dotis(_at_)mail-abuse(_dot_)org> 
wrote:


On May 25, 2009, at 1:45 PM, Amir Herzberg wrote:

 On Mon, May 25, 2009 at 6:54 PM, Douglas Otis 
<dotis(_at_)mail-abuse(_dot_)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 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
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg




-- 
Amir Herzberg
Associate Professor, Dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] Current Thread [Next in Thread>