[Asrg] enough about backscatter

[Douglas Otis]

On Jan 16, 2009, at 3:47 PM, J.D. Falk wrote:

> On 16/01/2009 03:50, "John Levine" <johnl at taugh.com> wrote:
>
>> Perhaps it's time to amend the ASRG charter to exclude easily  
>> visualized but actually hypothetical threats.  If you disagree that  
>> they're hypothetical, first you have to go get real data to support  
>> your claim.
>
> +1
>
> However, I wouldn't mind discussion about /how/ to get real data....

Some decisions depend upon doubts expressed of potential threats.   
Proponents are likely to insist a threat is only theoretical and do  
little more than make poorly considered comparisons.

Proving a point will likely require staging a vectored attack  
exploiting recipient resources, which seems dangerous from a legal  
standpoint.  Anything less is likely to be dismissed.  MTA  
administrators appear to pay little attention to a problem not  
directly effecting them.  In the meantime, the problem results in a  
greater number of confidence artist victims, and millions of dollars  
in damages occur due to DDoS attacks against those reporting on spam  
or malware threats, for example.  Unfortunately, these attacks rarely  
target MTA administrators who seem willing to look the other way.   
After all, the championed path registration schemes can be structured  
to deflect accountability away from the MTA.  The excuses for doing  
this can be found in appendix D of the Authentication-Results header  
draft.

See:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-19.txt

With the introduction of the Authentication-Results header, the  
underlying goal becomes clearer as a scheme to deflect assessments  
away from the MTA onto that of an authorizing domain.  Basing  
treatment upon an authorizing domain allows an MTA that may suffering  
from compromised access to remain otherwise unimpaired.  The  
Authentication-Results draft never stipulates that the authentication  
results  header should not be added without making a reputation check  
of assumed protections.  Only that the results of this header should  
not be revealed without a reputation check, which included an example  
of a phishing domain.  Of course, no phishing domain should be  
accepted, let alone given an Authentication-Results header right?   
Nevertheless, this check is to be made prior to revealing the content  
of this header, a function likely provided by the MUA.

Those revealing these results are required to assume the authorizing  
domain's reputation had been checked in a manner that directly  
pertains to identity being asserted without the check ever being  
directly indicated within the header.  The draft also states that,  
given the passage of time, rejections (rather than annotations being  
withheld), might occur when MUAs are allowed to ensure these checks  
separately.  This draft seems happy to have checks made against the  
local-part and domain, while also stating that there is a DDoS concern  
regarding the use of the IP address of the SMTP client.  Checks  
against the local-part and the domain represent several orders of  
increased overhead as compared to what is required of the IP address  
of an SMTP client.

Take for example the SPF local-part macros.  These macros are almost  
_never_ legitimately used, and _can_ be exploited by spam campaigns to  
leverage cached SPF records when constructing vectored DDoS attacks  
that do not expend additional resources of the attacker.  It is fairly  
normal to see millions of bot-net sources (IP addresses) becoming  
active for short intervals out of a set of several hundred million  
that may have been dormant for months to years.

Although concern has been expressed about how these macros can be  
exploited, and how impractical it is to use local-part macros to  
produce positive assertions, nothing seems to deter this feature from  
being institutionalized as a means to obtain message annotations as is  
now required by the Authentication-Results header draft!   When one  
wants their email to be noticed, this draft stipulates the use of  
local-part macros as an unintended requirement.

Of course, including the IP address within the Authentication-Results  
header permits a means to mitigate difficult problems that might be  
related to compromised servers or BGP route injections that completely  
defeat path registrations, but this protective information is  
purposely omitted.  The period that separates a message being received  
to when it is handled by the MUA provides valuable time to offer  
protection in the way of annotation.  Instead the draft conflates  
annotation with that of message rejection.  The MailMan program  
running many of the IETF mailing lists handles and annotates messages  
behind the MTA, where the use of RFC 3464 becomes important.  If if  
something more elaborate were to be implemented by the MUA, there are  
solutions in current use to mitigate these threats.  A reputation  
service can easily extend the time of a reporting by indicating the  
number of hours since a threat has been  resolved.  An annotation can  
be applied perhaps just in time, or not depending upon the threat  
information that relates to the actual source of the message, the SMTP  
client.

-Doug