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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Jun 2004 17:56:13 -0700

> > <>
> > Caller-Id required a single packet in each direction for the vas[t]
> > majority of mail interactions.
> > <snip>
> 
> Please watch your tone.
> That's incorrect. Please read the earlier post to this thread at
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html
> as it argues that this is not the case.

I fail to see the connection between an argument that a 20% 
increase in data size due to use of XML is significant and 
the current claim that we risk bringing down the Internet
with Sender ID. 

> I don't see you addressing the concerns Doug raised.

There is a proof point here that it is possible to encode the
hotmail IP addresses in three packets of data, most records in 
one packet.

Ergo if we end up with something that is dramatically worse
than that, like an order of magnitude out there is something
really wrong with the protocol we have come up with.

> Perhaps you were arguing that all mail servers should rely on local 
> caching DNS servers that will cache all the word's active 
> LMAP records.
> If that's the case, then *perhaps* that does present a strong DDoS 
> defense.  Please confirm/flesh out.  Does it work in the face of 
> malicious macro SPF records?

Only if we decide to support the macro interface. I was hoping that
we would reject it on the grounds that all the use cases that have 
been stated can be implemented anyway.

If what you are trying to say is that there must be some limit to the
complexity of a query I think that is correct, clearly it is a bad
thing if records branch out indefinitely.

That is an issue that calls for a security consideration, not 
hysterical subject headers. 

> BTW, I wonder if it would make sense to specify that caching 
> DNS servers 
> MAY cache LMAP records for x hours, even if they have a short TTL.
> This would reduce DDoS exposure.  At what cost, and what's a good x?  
> Without this, it's appropriate to assume that the attackers 
> will publish LMAP records with TTLs ~= 0.

How about simply stating that if a MARID record is retreived and 
determined to be malicious an MTA SHOULD consider caching that
conclusion?

If malicious.com or compromised.com have a malicious record in
their DNS it should become apparent quite quickly.

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.

Even if the attack is comming from a zombie, it is worth at
least a thousand packets to be able to determine that there is
a likely zombie on a network somewhere. No more spam from you,
plus report it to the sysadmin responsible.

> MARID provides additional motivation for DDoS against the DNS.

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.

The attack that appears likely to me would be for the attacker to 
send a stream of DNS queries to sender.com which appear to come from
receiver.com so that sender.com decides to stop responding to 
requests from that site, then broadcast a stream of spam.

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.

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 28 Jun 2004 18:24:15 -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.

>hysterical subject headers. 
Ah, that's what set you off.  Please address paragraphs 1-3 or don't 
respond. 

>determined to be malicious an MTA SHOULD consider caching that
An alternative with pluses and minuses. 

>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.

>is not exactly an anonymous attack.
Again, how is a malicious actor identified automatically?

>DNS is going to be attacked and how such an attack would make it
Same way taking down BLs works.  It makes 'em problematic (e.g 
unreliable and/or very resource intensive), so folks stop using 'em.

>we need to do is to work out a way to close the loop.
And how do we do that?

---

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

Some more comments.

1)Just a note as to why this discussion is important:
It is very relevant to the current agenda item:

  - Due 2004-07-02: Decide if CSV is complimentary, parts to be 
incorporated, or dropped.
Does CSV's greater DDoS resistance matter a lot? Or not?

>>>majority of mail interactions.
Do you see why I feld that this statement was incorrect, at least?

>> Please read the earlier post to this thread at
>> <>I don't see you addressing the concerns Doug raised.
>>
>>... Does it work in the face of 
Well, we have a decision to make by 7/2, and currently, macros are in 
the spec and likely to stay, so our decision should be based on that.

>thing if records branch out indefinitely.
I'm confident that, without such limits, SPF is likely to be turned off 
due to attacks on users.
I'm saying that we need to explore further whether with limits high 
enough to allow necessary functionality, it can survive such attacks.

I asked before if you were arguing that all mail servers should rely on 
local caching DNS servers that will cache all the word's active LMAP 
records.
Are you?

I'm not trying to deep 6 SPF.  I'm trying to make it stronger and better 
by attacking its weaknesses virtually, while they are readily fixable.
Note, I recently expressed my support Unified SPF (which incorporates a 
CSV-like check).
BTW, I was surprised that the -01 SenderID drafts that came out didn't 
have any Unified SPF stuff in 'em.  I interpreted something Meng said to 
mean that I should expect to see it in a draft soon, so I'm still 
expecting that.