On Jan 16, 2009, at 3:47 PM, J.D. Falk wrote:
On 16/01/2009 03:50, "John Levine" <johnl(_at_)taugh(_dot_)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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg