On May 29, 2007, at 8:36 PM, Scott Kitterman wrote:
On Tuesday 29 May 2007 17:53, Douglas Otis wrote:
SPF does not scale well and creates a significant DDoS concern.
FWIW, the SPF project did a serious analysis of Doug's concerns and
found that Doug's concerns are overblown with the processing limits
in RFC 4408. SPF does not present any unique DDoS concerns. I
realize this is OT for a DKIM list, but I'm getting tired of it.
I've sat back and said nothing about this nonsense for some time,
but the DDoS concern is one that only Doug seems to have. SPF has
a number of arguments against it, but this isn't one of them.
http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis
Analysis by the SPF project is not surprisingly biased. It ignores
several important aspects. Problems related to NS record
transactions are orthogonal to SPF, and can be addressed solely by
affected DNS servers. SPF is not within the realm controlled by DNS
protocol, except by having DNS drop SPF records entirely. It might
come to that.
For example, their analysis ignores the impact of the SPF local-part
macro capability. How this mechanism might be utilized is
demonstrated in the spf-dos exploit draft. This "feature" provides a
resource-free means for staging a DDoS attack in conjunction with
_any_ typical spam run. Many spam runs employ millions of SMTP
clients. Amplifications noted in the spf-dos exploit draft are
generous to SPF, as these figures should not include spam traffic.
When spam traffic is discounted as a given, the resulting
amplifications better clarify benefits bad-actors obtain exploiting
SPF. Consumption of an attacker's resources are eliminated! The
same SPF cached record is able to induce an _infinite_ number of
transactions against _any_ innocent domain, making such attacks
directed anywhere virtually free. No one is safe. Perhaps the spf-
dos draft needs to be updated.
The name-path draft was to illustrate that safe alternatives can be
devised. The name-path draft was not intended as a marketing ploy or
self promotion, as their analysis suggests. Am I making myself
popular discussing this issue?
Statements that SPF only increases the number of existing
transactions by 10 is wrong. Libraries in accord with RFC4408 exceed
100 new and directed transactions. A vast number of poorly written
libraries will not impose _any_ subsequent address resolution limits,
a detail their analysis also ignores. 40+ pages in the spf-dos
exploit draft represents a redacted trace of just _one_ call to an
RFC 4408 compliant library resolving _one_ email-address. The trace
clearly illustrates a much greater number of transactions are
generated. Adding limits for the number of "no domain" responses
would only make SPF more unreliable when so many records might
legitimately be involved. Early termination of the SPF script
process defeats congestion avoidance, making SPF a serious threat
indeed. Even with tighter limits, an SPF DDoS attack remains free.
Many spam runs are more than wide enough to cause considerable
damage, even when fewer transactions are permitted. Preventing or
filtering the attack will be impossible.
Doug, this really isn't the forum to be discussing the merits of
SPF. It attempts to solve a different problem than DKIM and that's
probably enough for this list.
Jim Fenton himself suggested SPF could be used in conjunction with
DKIM to resolve possible replay problems. Corporate marketing is
busy promoting Sender-ID. Whether it is DKIM or Sender-ID, SPF works
like a script which must be "run" to obtain an answer. As such, each
additional domain MUST invoke a full set of SPF related transactions
which only adds to the loathsome DDoS gains possible.
The DKIM WG is free to ignore likely problems caused by replay abuse
caused by reputations based upon DKIM domains. Problems likely to
disrupt several valid email use scenarios. Even per-user key with a
TTL of zero is unlikely to dissuade abusive replays. Abusive
replays, even for a few hours, greatly exceeds volumes otherwise
permitted by constraints normally in place. And what level of DNS
instability is acceptable?
Ending with a happy and on topic note, an authorization By-Name
scheme, used in conjunction with DKIM, can also allow MAIL FROM
addresses to be authorized. This would provide a safe means to
curtail a DKIM bounce with a "broken" signature exploit. A message
with an authorized MAIL FROM might even be more likely accepted on
that basis alone, as it would not add to the backscatter problem when
it gets bounced. Much like Google increases the ranks of web pages
referenced elsewhere, an authorization By-Name scheme provides a new
type of reputation based upon those trusting the domain to handle
their email.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
