DNS-based Email Sender Authentication Mechanisms: a Critical Review

[amir.herzberg]

Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID Framework (SIDF); it's in process of publication at `computer & security`, you can see it at http://dx.doi.org/10.1016/j.cose.2009.05.002 (pending editing, final changes etc.). Nothing much new, just an attempt to provide a fair-yet-critical survey, hopefully to help clarify this important subject. Comments will be most welcome. Abstract below.

Amir Herzberg

Title: DNS-based Email Sender Authentication Mechanisms: a Critical Review

Abstract

We describe and compare three predominant email sender authentication mechanisms based on DNS: SPF, DKIM and Sender-ID Framework (SIDF). These mechanisms are designed mainly to assist in filtering of undesirable email messages, in particular spam and phishing emails.We clarify the limitations of these mechanisms, identify risks, and make recommendations. In particular, we discuss potential abuse of these mechanisms to facilitate DNS poisoning, and suggest countermeasures.

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

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Dave Crocker-2]

US$ 31???

Intelligent articles in this arena are rare.  Too bad this one is effectively
inaccessible.

d/


Amir Herzberg wrote:

> Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID
> Framework (SIDF); it's in process of publication at `computer &
> security`, you can see it at
> http://dx.doi.org/10.1016/j.cose.2009.05.002 (pending editing, final
> changes etc.). Nothing much new, just an attempt to provide a
> fair-yet-critical survey, hopefully to help clarify this important
> subject. Comments will be most welcome. Abstract below.
>
> Amir Herzberg
>
> Title: DNS-based Email Sender Authentication Mechanisms: a Critical Review

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Steve Atkins]

On May 24, 2009, at 12:58 AM, Amir Herzberg wrote:

> Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID  
> Framework (SIDF); it's in process of publication at `computer &  
> security`, you can see it at http://dx.doi.org/10.1016/j.cose.2009.05.002 
>  (pending editing, final changes etc.). Nothing much new, just an  
> attempt to provide a fair-yet-critical survey, hopefully to help  
> clarify this important subject. Comments will be most welcome.  
> Abstract below.

I'm not going to pay $31.50 to review someone's work. Nor is anyone  
else, I suspect.

Cheers,
   Steve

>
> Amir Herzberg
>
> Title: DNS-based Email Sender Authentication Mechanisms: a Critical  
> Review
>
> Abstract
>
> We describe and compare three predominant email sender  
> authentication mechanisms based on DNS: SPF, DKIM and Sender-ID  
> Framework (SIDF). These mechanisms are designed mainly to assist in  
> filtering of undesirable email messages, in particular spam and  
> phishing emails.We clarify the limitations of these mechanisms,  
> identify risks, and make recommendations. In particular, we discuss  
> potential abuse of these mechanisms to facilitate DNS poisoning, and  
> suggest countermeasures.
>
> --
> Amir Herzberg
> Associate Professor, Dept. of Computer Science
> Bar Ilan University
> http://AmirHerzberg.com
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Sean Shuo Shen]

> On May 24, 2009, at 12:58 AM, Amir Herzberg wrote:
>
> > Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID
> > Framework (SIDF); it's in process of publication at `computer &
> > security`, you can see it at
> > http://dx.doi.org/10.1016/j.cose.2009.05.002
> >  (pending editing, final changes etc.). Nothing much new, just an
> > attempt to provide a fair-yet-critical survey, hopefully to help
> > clarify this important subject. Comments will be most welcome.
> > Abstract below.
>
> I'm not going to pay $31.50 to review someone's work. Nor is
> anyone else, I suspect.
>
> Cheers,
>    Steve

I got very surprised that on asrg mailinglist I was induced to pay and
review a paper. Is this a mistake or an advertisement?

Sean
 

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[grenville armitage]

Sean Shen wrote:
        [..]
> on asrg mailinglist I was induced to pay and
> review a paper. Is this a mistake or an advertisement?

Chill, people. The original email didn't solicit reviews,
just comments (seems to me the author just wants to stimulate
discussion). The original author wont be getting any of the money.
As is common in academic research, papers get published in
journals who often charge money for online access to papers.
This paper is essentially free to staff and students of companies
(often universities and some R&D labs) with institutional licenses
for online papers. Wouldn't surprise me if the original poster didn't
even realise the journal was charging for access. Yes, other people
miss out - which is unfortunate, but hardly a conspiracy to undermine
the ASRG.

cheers,
gja

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Jose-Marcio Martins da Cruz]

Amir should send it to the list before sending it to be published by Science Direct. I'm
not sure, but it seems to me that even he, he can't distribute a copy of the paper, now.
Unfortunately.

I have a copy of it (but I haven't yet read it), as our library subscribes to that
service, but, as long as I know, I can't either redistribute it.

Cheers,



Steve Atkins wrote:

>
> On May 24, 2009, at 12:58 AM, Amir Herzberg wrote:
>
>> Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID
>> Framework (SIDF); it's in process of publication at `computer &
>> security`, you can see it at
>> http://dx.doi.org/10.1016/j.cose.2009.05.002 (pending editing, final
>> changes etc.). Nothing much new, just an attempt to provide a
>> fair-yet-critical survey, hopefully to help clarify this important
>> subject. Comments will be most welcome. Abstract below.
>
> I'm not going to pay $31.50 to review someone's work. Nor is anyone
> else, I suspect.
>
> Cheers,
>   Steve
>
>
>>
>> Amir Herzberg
>>
>> Title: DNS-based Email Sender Authentication Mechanisms: a Critical
>> Review
>>
>> Abstract
>>
>> We describe and compare three predominant email sender authentication
>> mechanisms based on DNS: SPF, DKIM and Sender-ID Framework (SIDF).
>> These mechanisms are designed mainly to assist in filtering of
>> undesirable email messages, in particular spam and phishing emails.We
>> clarify the limitations of these mechanisms, identify risks, and make
>> recommendations. In particular, we discuss potential abuse of these
>> mechanisms to facilitate DNS poisoning, and suggest countermeasures.
>>
>> --
>> Amir Herzberg
>> Associate Professor, Dept. of Computer Science
>> Bar Ilan University
>> http://AmirHerzberg.com
>> _______________________________________________
>> Asrg mailing list
>> Asrg@...
>> http://www.irtf.org/mailman/listinfo/asrg
>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>

--
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:Jose-Marcio.Martins@...
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[amir.herzberg]

gja, thanks, you got the situation correctly. In fact, from our campus, access to this publication is free in transparent manner, so I quite forgot that it is not free to all... sorry! Tks to others who have explained the situation on the list or to me (off-list).

Anyway, Elsevier's copyright conditions are very reasonable and in particular they do allow me (i.e., authors) to post pre-published versions in personal site, so I've put it on my googlepages at: http://amir.herzberg.googlepages.com/somerecentpapers.

I hope this is now acceptable and people don't suspect me of `spamming' just for sending a link to a related review paper (some people complained I'm `spamming' but I hope they just thought I'm trying to actually convince you to pay for the paper... at least, I hope that's what they meant).

Have great day, Amir Herzberg

On Mon, May 25, 2009 at 10:16 AM, grenville armitage <garmitage@...> wrote:

Sean Shen wrote:
       [..]

on asrg mailinglist I was induced to pay and
review a paper. Is this a mistake or an advertisement?

Chill, people. The original email didn't solicit reviews,
just comments (seems to me the author just wants to stimulate
discussion). The original author wont be getting any of the money.
As is common in academic research, papers get published in
journals who often charge money for online access to papers.
This paper is essentially free to staff and students of companies
(often universities and some R&D labs) with institutional licenses for online papers. Wouldn't surprise me if the original poster didn't
even realise the journal was charging for access. Yes, other people
miss out - which is unfortunate, but hardly a conspiracy to undermine the ASRG.

cheers,
gja

_______________________________________________
Asrg mailing list
Asrg@...
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@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

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.  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.

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.

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.

SPF enables both sustained DDoS attacks and is able to bypass  
protections otherwise afforded by ACLs on local resolvers.  It seems  
that risk should be mentioned in a critical review.

-Doug






_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[der Mouse-3]

> Suggesting the use of DNSSEC is not reasonable justification for
> ignoring this problem.

Why not?

I see nothing wrong with the stance of "if you stubbornly refuse to
deploy known solutions to the problem, you will have to live with
continued exposure to the problem".  For example, nobody sheds a tear
over the insecurities in rsh, because we have ssh; why do you feel the
analogy to unsecured DNS and DNSSEC is invalid?

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTML mouse@...
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

Douglas Otis <dotis@...> 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.

   Doug perhaps asks too much... But the paper does explain a particular
exploit, where SPF records are used to cause particular DNS queries at
"known" times, to which forged responses can be spoofed, potentially
greatly increasing the risk of DNS poisoning.

   Discussion of that particular exploit does seem in scope.

   The paper is somewhat disappointing in only mentioning "rate limiting"
and "dedicated DNS proxy" as countermeasures, without any particulars.

   Is there any interest in fleshing out these countermeasures?

> 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.

   This sounds like the sort of issue where a "dedicated DNS proxy"
for SPF queries could apply rate-limiting to good advantage. Of
course, it would end up deliviering "less" than SPF proponents have
been claiming as SPF's "advantages;" but I suspect Doug is not alone
in considering such a "feature" as beneficial.

   ;^)

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On May 25, 2009, at 8:59 AM, der Mouse wrote:

>> Suggesting the use of DNSSEC is not reasonable justification for  
>> ignoring this problem.
>
> Why not?
>
> I see nothing wrong with the stance of "if you stubbornly refuse to  
> deploy known solutions to the problem, you will have to live with  
> continued exposure to the problem".  For example, nobody sheds a  
> tear over the insecurities in rsh, because we have ssh; why do you  
> feel the analogy to unsecured DNS and DNSSEC is invalid?

Selecting which shell access method to use does not depend upon prior  
adoption by the rest of the Internet.  A requisite massive adoption of  
DNSSEC before a reasonable level of protection is obtained is where  
this analogy fails.

The major proponent of Sender-ID still does not offer DNSSEC, and has  
only recently announced DNSSEC in their future OS versions.  Even when  
DNSSEC becomes available, validating resolvers will need to be  
configured with “trust anchors” for zones where validation is  
possible.  DNSSEC had expected resolvers would be configured with a  
trust anchor at the root zone, however, the root zone is not signed at  
this time, nor are most of the TLDs.

Until that time, multiple trust anchors are required for DNSSEC, where  
servers will need to be configured to accept some unsigned  
information.  Secondly, use of DNSSEC also requires EDNS0, which  
actually makes the SPF macro feature, in conjunction with with the  
inordinate number of transactions created by recipients processing  
SPF, even more dangerous from an DDoS perspective.

The safest method for deploying DNSSEC could be by using SCTP as a  
preferred transport for DNS.  Even this type of conclusion is likely  
another decade away.  Until then, not being abusive and remaining  
cautious about DNS use remains the best current advice.

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[amir.herzberg]

On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <dotis@...> 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

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Jose-Marcio Martins da Cruz-3]

Amir Herzberg wrote:

> On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <dotis@...
> <mailto:dotis@...>> 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!

Well. Me too, I don't understand why it could be interesting to check SPF in the MUA. It
may be interesting to check SPF when one have access to both sender domain and IP address
of the SMTP client connecting to the MTA. This information isn't usually available to the
MUA, unless it will trust on data available on headers.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

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

>> On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <dotis@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@...
http://www.irtf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Jose-Marcio Martins da Cruz wrote:

> Well. Me too, I don't understand why it could be interesting to check SPF in the MUA. It
> may be interesting to check SPF when one have access to both sender domain and IP address
> of the SMTP client connecting to the MTA. This information isn't usually available to the
> MUA, unless it will trust on data available on headers.

The Thunderbird SPF/DK plugin, for example, has a configuration option
that tells it how to parse the Received lines to pluck out the IP and
HELO recorded in the Received line the user's perimeter MTA has generated.

It works well enough in that regard.

[The plugin isn't compliant with SPF per-se, it checks From:, because it
usually can't get the MAIL FROM.  This is configurable.]

I experimented with it.  It works.  But doesn't add enough to be worth
while if you already have decent MTA-end filtering.

If you don't have decent MTA filtering, it might be worthwhile.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[amir.herzberg]

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@...> 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
Asrg@...
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@...
http://www.irtf.org/mailman/listinfo/asrg

[Jose-Marcio Martins da Cruz-3]

Chris Lewis wrote:
>
> I experimented with it.  It works.  But doesn't add enough to be worth
> while if you already have decent MTA-end filtering.
>
> If you don't have decent MTA filtering, it might be worthwhile.

OK, but... Well, you said "if you don't have decent MTA filtering".

Looks like "hack", "workaround", ...

IMHO, one of the problems in spam filtering is that we're allways including and accepting
the existence of bad solutions, bad administered mail servers, bad practices, ...

It seems to me that ASRG should, first of all, encourage best practices.


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Douglas Otis wrote:
> The safest method for deploying DNSSEC could be by using SCTP as a
> preferred transport for DNS.

Just using TCP would prevent most of the DNS poisoning attacks that
Amir's paper reports.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Dave Crocker-2]

Amir Herzberg wrote:
>     Nothing much new, just an attempt to provide a
> fair-yet-critical survey, hopefully to help clarify this important
> subject. Comments will be most welcome. Abstract below.
>
> Amir Herzberg
>
> Title: DNS-based Email Sender Authentication Mechanisms: a Critical Review


Perhaps I misunderstand the paper, but it appears to be asserting that DKIM
validates the From: field.

>      DKIM allows authentication of multiple
> email header fields, including the sender identity displayed to the recipient; in
> that regard, it is similar to SIDF

Since DKIM does nothing of the kind, that seems a rather fundamental point of
departure for evaluating the paper.

DKIM authenticates the signing domain, and it ensures data integrity for the
covered header fields and body, from the place of signing to the place of
verification.  But it does not authenticate any of the message contents, such as
the sender identity.

d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On May 26, 2009, at 10:59 PM, Amir Herzberg wrote:

> 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].

A warning is likely not something a typical user would know how to  
control.  SPF record processing is found lurking in many places.  
Within AV and various email filtering and annotation schemes that do  
not indicate the processing of SPF records will occur.    
Unfortunately, some of these schemes are rather poorly written and  
even lack some of the recommended albeit generous processing limits.

> 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.

The important aspect of this concern is that SPF _macros_ allow the  
SPF record itself to be cached and thereby not expend _any_ additional  
resources of the attacker.  Macro expansion of cached SPF records by  
recipients can generate 10x transactions as a completely free gift to  
the attacker!   This free attack eliminates a major factor that  
discourage most DDoS attacks.  This represents an indirect attack that  
is difficult to trace,  that is likely not logged, and is  
substantially free because a final transaction, or even the end of the  
SPF record, can result in full authorization regardless of the MTA IP  
address.

-Doug


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg