Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Jun 2004 19:53:38 -0700

> >I fail to see the connection between an argument that a 20% 
> >
> That's not what I'm talking about.  Consider the whole post, 
> particularly paragraphs 1-3.  Arrgh.
> The URL is above.

How about you or Doug try to post a clear attack scenario
that shows exactly how such an attack would be performed?

I have great difficulty parsing the paragraphs, let alone making
sense of statements such as 

"If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities. "

It is a matter of indisputable fact that all interpretation of
DNS records requires the use of some form of parser. So the 
above appears to be nonsense.

"The
less rigid and more extensible the syntax, the greater the
vulnerabilities. "

It is also a matter of indisputable fact that XML can be parsed
using a finite state machine of less than 20 states acompanied by
a simple stack. I have written such a parser several times.

It would therefore seem to me that the competence of the coder is
the significant factor here rather than the choice of syntax
which is at any rate moot at this point.

Having got to the end of paragraph 1 I am unable to find any
issue of relevance outside the XML debate, is it possible that
you have given the wrong URL?

"An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs."

So a DDoS attack on your own ability to send email. this can
be addressed by a security consideration. If you have to resolve
more than X records then consider the data spurious and reject
the mail.

"As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size."

Assume that three contain powerpoint presentations of 1Mb, four
contain word documents of 500Kb and five pictures of little Timmy.
that would be a more realistic load, but it would prevent the
dire conclusion

"These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load."

assuming the attack is present on every email. And the mail server 
does not get clever and stop accepting emails from malicious IP addresses.

Estimates of the number of compromised hosts on the Internet vary, but 
the highest number in a botnet tends to be in the tens of thousands.
If the attacker is using a different bot for each connection that
is 3000 bots per minute, 180,000 per hour.

This is an attack I really really would like to see, we could map 
out the zombies on the Internet pretty quick.

[Why not just DDoS the email server direct and have done with it????]

> >That is an issue that calls for a security consideration, not 
> >hysterical subject headers. 
> >  
> Ah, that's what set you off.  Please address paragraphs 1-3 or don't 
> respond. 

Please give a clear statement of the issue you are trying to raise.
Repeated claims that the issue has been stated do nothing at all.

> >If malicious.com or compromised.com have a malicious record in
> >their DNS it should become apparent quite quickly.
> >  
> >
> I don't see how.  Say 9/10s of a domain's record resolves. 
> How is this 
> domain identifiable as malicious?
> Maybe it's just under attack.

If it is under attack then it probably should be ignored until
it recovers. All the mail 'from' that source is most likely spam
anyway.

> >Also remember that the sender has to be holding an open TCP
> >session during this process with a known source IP port. This
> >is not exactly an anonymous attack.
> >
> Again, how is a malicious actor identified automatically?

By logging the IP address of the source of the attack.

> >The argument makes no sense unless you can state which part of the
> >DNS is going to be attacked and how such an attack would make it
> >easier to send spam.
> >  
> Same way taking down BLs works.  It makes 'em problematic (e.g 
> unreliable and/or very resource intensive), so folks stop using 'em.

BLs have a single point of failure that is similar to the problem
of running core DNS, you take down one part of the network and in
time the rest of the net grinds to a halt.

You have failled to show that there is a dependency that looks anything 
like the dependency that a mail server has on a BL or on core DNS.

> >Seems to me that any such attack has the problem that the attack
> >and likely motive become immediately obvious to sender.com. All
> >we need to do is to work out a way to close the loop.
> >  
> >
> And how do we do that?

Reporting mechanism to allow sender.com to tell receiver.com that it
is observing large numbers of packets that appear to be emitted 
from that domain.

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 28 Jun 2004 20:57:45 -0700

On 6/28/04 7:53 PM, Hallam-Baker, Phillip sent forth electrons to convey:

> <unparseable>
Again, how is this domain identifiable as malicious?  Many of your 
points are predicated on having this ability.

>By logging the IP address of the source of the attack.
Sorry, but what attack?  You have to identify the attack as an attack 
first; see above.

>like the dependency that a mail server has on a BL or on core DNS.
What part of "it makes them very resource intensive, so folks stop using 
'em" don't you understand?

Here's the three paragraphs, with some editing by me.
I'm sorry if you don't understand them, but they are clear.
It has nothing to to with XML (which is dead, WRT MARID), at least now.

Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack.  ...  As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.

An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs.  The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel.  (If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn
also outsource for yet more chaining.)         

For example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 10 queries with an average of 5 seconds a query,
then this limits each process to about 1 message about every minute. 
These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second.  This may still represent the same amount
of network traffic, just half as much mail gets through the network.

You cannot redefine the size of the emails the attacker sends to make the attack less effective.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jun 2004 21:22:18 -0700

> that shows exactly how such an attack would be performed?

I thought it was clear.

> answers, so the introduction of a parser increases vulnerabilities. "

I could have said it takes no "additional" parser to utilize A records
or SRV records or many other binary responses offered by DNS.

> above appears to be nonsense.

But the task to parse a SPF requires an additional parser added where
either the increase in resources needed or errors created handling
malformed input exits where there would have been none if such a parser
was not added.

> a simple stack. I have written such a parser several times.

The larger these records are allowed to grow or the greater their
numbers, the greater their risk. I thought the XML issue was resolved. 
I have yet to see any evidence of this however and this question seems
odd in that respect.

<snip>
> more than X records then consider the data spurious and reject

Exactly.  The goal would be to slow reception and thereby allow greater
distribution to a larger array of servers.  What is this limit?  What is
the average number of references to other domains?

> that would be a more realistic load, but it would prevent the

This was not assuming a bandwidth limitation.  I only attempted to
illustrate that at half the number of messages, the traffic was not
changed.

> does not get clever and stop accepting emails from malicious IP addresses.

This could easily be happening from 80,000 addresses.  This is a small
number out of millions possible.  I would not expect too much effort
made from normal tactics however.

> is 3000 bots per minute, 180,000 per hour.

Such an estimate is low, but using your 10,000 with just 56 k baud links
and .4k per message, that would be 175,000 messages per second.  If able
to reduce mail performance to 25 messages per second, the attack could
hinder 7000 mail servers.  Bad news for someone I would suspect.

> out the zombies on the Internet pretty quick.

How?  You may have captured a series of dynamic IP addresses and others
that simply were transferring real mail.  Of these messages, none were
rejected as they contain nothing to indicate them to be spam.  None of
the domains in the return path were from closed lists.  You will have
made little progress in knowing anything for certain.

> [Why not just DDoS the email server direct and have done with it????]

The attack is to convince providers SPF is not worth it.

<snip>
> > How is this domain identifiable as malicious?

If there is a slow response to a DNS query, then this identifies the
source as a spammer?  What type of behavior are you recommending?

> By logging the IP address of the source of the attack.

How do you identify the attacker?  What is different?  
  
> like the dependency that a mail server has on a BL or on core DNS.

I would say there is no analogy with a BL and an MTA checking SPF
records.  A BL can be scaled to handle DoS attacks as there would be an
interest to ensure such. Those running mail will now find themselves
under attack as a result of a flood of DNS queries resulting from
spoofed mail to MTAs employing the SPF mechanism.
 
> is observing large numbers of packets that appear to be emitted 

A reporting mechanism to increase the MTA load during a possible attack
that can not identify the source of the attack, but knows it is being
attacked because it is taking too long to query DNS?  What is the source
of a well disguised distributed attack anyway?

-Doug

---

From: Greg Connor <[email-masked]>
Date: Mon, 28 Jun 2004 22:06:48 -0700 (PDT)

> 'em" don't you understand?

I am going to agree with Phillip on this one.  SPF queries don't go to a 
central location, they go to the spammer's DNS server (or that of whoever the 
spammer is trying to impersonate.  It sounds like the worst they could do 
would be to make the receiving mail server really busy, stop their own mail 
from getting through, or pick on one or two other domains that have weak 
nameservers.  I don't see a type of attack that erodes DNS in general for 
everybody.  Furthermore, the spammer is exposing his own IP during the attack 
so he should be blocked quickly.

> You cannot redefine the size of the emails the attacker sends to make the attack less effective. 

This seems reasonably clear, but it doesn't identify a damaging attack.  Is 
the attacker trying to get his message through, or just trying to make trouble 
for the receiver?

We get a lot of spam (attempts anyway) from domains that don't resolve due to 
timeouts.  That means the spammer is already causing resolvers to time out and 
mail servers to keep connections open for as long as it takes to time out.  
So, if the main element of the theoretical attack is "lots of mail sent at 
once and it makes the resolver do lots of queries that time out" -- I think we 
already have the problem today and are dealing with it.  (In several cases I 
have had to install DNS servers directly on the mail server box to keep it 
from bogging down our normal nameserver.)

In other words, there are already a number of DNS queries being done per 
message, and many of those time out.  5 more or even 20 more DNS queries are 
probably not as harmful as, say, increasing the incoming smtp connections, or 
consuming SMTP sockets with spoofed SYN packets or something.

Now, I think it's actually interesting to compare this type of attack scenario 
with normal spam.  Normal spam may be from a domain that doesn't resolve 
properly, but if the result is a timeout (for spf or for just resolving the 
MAIL FROM and its MX) then you don't get to go on to the next step.  If the 
DNS responds well enough to keep the connection alive, then the spam is 
accepted (which consumes more bandwith than the DNS lookups) and sent to 
SpamAssassin (which consumes CPU, the steps before haven't relied on CPU 
much).

In other words, it is likely that taking a normal spam run and adding 
recursive SPF queries that respond erratically and don't cache well, might 
shift more load onto the resolver, but the more effective it is at weighing 
down the resolver, the more likely the spam will get a 454 answer and not go 
on to DATA.  In that case I get my bandwidth back and I get my CPU back, so 
the impact is actually less than a normal spam run, approximately.

Anyway, if the point of all this is "We should ensure that LMAP queries aren't 
allowed to be chained more than X deep" or "We should test to make sure that 
complicated SPF queries don't adversely affect the mail server or its dns 
server" I would agree with that.  I wouldn't describe this as a new attack 
vector however... anything that starts with "Assume a large number of incoming 
SMTP connections..." ought to be familiar territory to any mail server 
operator :)

Later
gregc
--
Greg Connor
[email-masked]

Everyone says that having power is a great responsibility.  This is a lot
of bunk.  Responsibility is when someone can blame you if something goes
wrong.  When you have power you are surrounded by people whose job it is
to take the blame for your mistakes.  If they're smart, that is. 
                -- Cerebus, "On Governing"

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 28 Jun 2004 23:17:10 -0700

Doug just responded rather eloquently to this thread, I'll try my best.

On 6/28/04 10:06 PM, Greg Connor sent forth electrons to convey:

>everybody. 
Again, the attacker's immediate goal is just to get folks to stop using SPF!

> Furthermore, the spammer is exposing his own IP during the attack 
Huh? He's got a zombie army, and AGAIN, how do you identify the attack 
as an attack?

The latter!!! Quoting myself:

>What part of "it makes [SPF] very resource intensive, so folks stop using 
>[SPF]" don't you understand?

>timeouts. 
Sure, but I bet it's a small fraction.

> That means the spammer is already causing resolvers to time out and 
That's generally one query to a possibly non-responding nameserver per 
message, not < 20 or < infinity, .

>from bogging down our normal nameserver.)
You can deal with it being 100 x worse?

>consuming SMTP sockets with spoofed SYN packets or something.
Possibly.  But these wouldn't achieve the attacker's goal. And only a 
small fraction of  these DNS queries time out.

>the impact is actually less than a normal spam run, approximately.
Well, you get your CPU back, but Doug is arguing that the bandwidth is 
spent on the SPF queries - ~4k/message.
But this is a valid point you make; there is the potential for some win.

>SMTP connections..." ought to be familiar territory to any mail server 
No.  The second half of the sentence could be something they're 
completely unfamiliar with.  In this case, it may well be.

---

From: [email-masked]
Date: Tue, 29 Jun 2004 15:33:49 -0400

> so he should be blocked quickly.

OK... I admit I tuned in late... but somehow, it's rather surreal to see
"We have their IP so they should be blocked quickly" as a justification.

In what way will they be "blocked quickly"?  And how will this be an
improvement over the blazing speed we currently see on shutting down
spam-spewing zombies that we know the IP address of?

---

From: [email-masked]
Date: Tue, 29 Jun 2004 15:33:49 -0400