spf-discuss
[Top] [All Lists]

Re: Security Paper on forgery bounce DDoS

2004-04-18 11:35:03
In <MHEGIFHMACFNNIMMBACAEEDAHMAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com> 
"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:

With regard to HTTP, I'd be surprised if the cost of a CBV to the message
recipient MTA is nearly as high as anything based on HTTP.  While it is
certainly more expensive than a UDP DNS query, it is about as short an SMTP
session as is possible.

Erh?

Both HTTP and SMTP use TCP/IP, so they both require a three-way
handshake on connection create and a four handshake for closing the
connection.  The HTTP requires one command to be sent (one packet) and
one response packet to be recieved (on packet).  A CBV via SMTP is
going to require exchanges for the HELO, MAIL FROM: and RCPT TO
commands.  The receiving SMTP server will also likely do a bunch of
other DNS checks to filter out the spam sources.

My guess for SPF using UDP-DNS vs TCP-HTTP was a factor of 10.  Others
said it is likely higher, James measured it at over a factor of 9.


My guess is that CBV is at least a factor of 2 or maybe even 3 more
than HTTP.

You are making claims about stuff that you haven't looked at
carefully.



      SES returns a binary result, pass or fail, from the domain MX, which
the domain owner generally has more control over than SPF implementations at
other sites.

Again, no SES+CBV does *not* return a binary pass-fail result.  It
returns an indeterminate-fail result.


This is part of what I meant by "you get what you pay for".  A CBV is more
expensive than a DNS lookup, though as James Couzens described in his
outline of SPF processing, there is quite a bit more logic (CPU cycles) and
often additional DNS lookups, so it is not simply issuing a single DNS query
and getting a yes/no answer.

Several points:

First, the number of SPF DNS lookups is not the same as the number of
DNS packets on the net.  Many parts of the SPF checking will have DNS
cache hits because information about the domain's A and MX records
will likely be checked by the MTA anyway.  Specialized DNS caches that
understand the DNS usage of SPF can reduce this further.  


As far as CPU costs go, the CBV is going to be more expensive than
SPF.  I did some quick profiling on libspf-alt a while back, and the
largest use of CPU was the "sanitize" function.  It is the function
that makes one pass over all of the output to make sure there aren't
any invalid characters.

This, at first, surprised me, but after thinking about it, I realized,
for the most part, everything in libspf-alt is going to be
approximately a linear function of the bytes exchanged across the net
(e.g. SPF TXT record, DNS lookups, etc.).  Nothing that libspf-alt is
a huge amount more expensive than calling the very fast isprint() C
function, hence the sanitize() function, which makes effectively
several additional passes over the data, will rank very high.  (It has
to do one pass for the SMTP comment, one for the Received-SPF: header
comment and one for the Received-SPF: header itself.)

CBV is going to have very similar CPU usage since it also has to
scan/checksum/parse all the data sent across the net.

Therefore, since CBV uses more network resources, it will almost
certainly use more CPU cycles.

You are making claims about stuff that you haven't looked at
carefully.



6) SES does not require changes to RFC2821.  SRS violates RFC2821 by
changing the return-path in transit and requires changes to
RFC2821 to be compliant.

I think you're probably right on this one, too.

I think the difficulty of this one has been underestimated or largely
ignored.

Please explain why you think that SRS violates RFC2821.  As I said, in
the IETF WG studying this stuff, there doesn't seem to be any such
consensus.  This is an issue that I consider very important.  It has
certainly not been ignored by me, or by quite a few others.

You appear to be making claims about stuff that you haven't looked at
carefully.



Using SES (that is, applying SRS to all outgoing email) lets you
immediately start rejecting bogus bounces that are being sent back to
you, which is great.  I like that.  It doesn't allow the receiving MTA
to check the envelope-from without an expensive CBV.

I see no reason not to use both SES and SPF, along with something like
MS's Caller-ID, or Yahoo's DomainKeys, or S/MINE or something to
verify the mail headers.  These tools all allow you to solve different
problems, but they don't do a good job of solving every problem.


-wayne