Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review
2009-05-25 21:23:57
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.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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: DNS over SCTP, (continued)
- Re: [Asrg] DNS over SCTP (was: Re: DNS-based Email Sender Authentication Mechanisms: a Critical Review, SM
- Re: DNS over SCTP (was: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: a Critical Review, Francis Dupont
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Florian Weimer
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Florian Weimer
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, John Leslie
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review,
Douglas Otis <=
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Jose-Marcio Martins da Cruz
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Chris Lewis
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Jose-Marcio Martins da Cruz
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Chris Lewis
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, Alessandro Vesely
- Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review, der Mouse
- Re: [Asrg] rDNS, Douglas Otis
- Re: [Asrg] rDNS, der Mouse
|
|
|