Subject: RE: Forging (was Re: Differences between CSV and Sender-ID )

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jul 2004 16:06:53 -0700

> Trojans sending much of the viruses (for more Trojans) and spam (for
> revenue) are not concerned about full compliance to a 
> specification, nor do they implement proper states for an SMTP client.

OK.

> Why attribute abuse
> to malevolent intent when expediency is more likely a principle
> motivation. 

I don't care what the motivation is.

> So stopping a message after wasting the full bandwidth of
> the rejected message may seem like a small concern, but there may be
> another 100,000 more of these Trojans requesting service. 

I don't much care when the message is rejected. It is great if the
message can be rejected early on, but that does not mean that I
am going to reject a scheme just because it does not make this 
possible.

In the real world spam zombies have a finite life. Sure some 
botnets have 100,000 machines, most do not and there is a lot of
work going on to reduce the value of hijacked machines as spambots.

If you think there is a problem here, suggest a fix. spreading
FUD about a mechanism that is not intended to address the 
problem does not help.

> In addition, many of these spammers use a technique that appends a
> random sub-domain resolved using a wildcarded record as a means to
> obfuscate filters.  It also means data needed for a repeated 
> visit or a
> repeated message will not be in a DNS cache. A loss of even more
> bandwidth on the DNS queries, possibly more than from the 
> messages being checked.

Sounds like a very noticable scheme to me.

> > I believe most MARID DNS queries will be 1 or 2 per 
> transaction and can be 
> > cached easily.  I have seen nothing to suggest that the 
> relationship is 
> > other than linear.  Therefore I dismiss "these concerns" 
> which seem to 
> > suggest that the relationship is geometric or exponential 
> or whatever.  It 
> > doesn't make sense, and is not borne out by the early 
> adopters of SPF.
> 
> Could you explain the premise used for this assumption?

Observation of the deployed SPF records perhaps???

> > Hmm, this paragraph also seems to contain high FUD-to-fact ratio.
> 
> Sending hosts > Receiving hosts (increases scale and scope)
> Originating domains > Receiving domain (increases scale and scope)
> Receiving Domain sets > Receiving domain (increases scale and scope)

I do not have the slightest idea what point you are trying to 
make here and I don't think you do either.

> My premise is that abuse of published partial lists left open will
> ensure either the removal of these records, or an attempt to fully
> publish a comprehensive record set.  A desire to delegate to other
> domains providing services runs the risk that as they add a few
> indirections, this may cause hard errors and the complete loss of mail
> service without the administrator of the domain having done anything
> atypical or perhaps having done nothing.

The posts I made earlier describing a means of applying a restriction 
on indirections have not made it to the list yet.

It is really easy to do.

> Using an assumption that Sender-ID records are able to limit the
> required queries to 10 and set the "transientError" timeout at 10
> seconds, what will be the impact on network integrity?

If you end up with a problem process offline, but I don't see why
a problem should arise.

The Internet stops working if you hypothesize worst case response
for every transaction, so what? we knew that.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jul 2004 18:58:40 -0700

> You have not offered simulations for traffic flow to counter this
> claim.  You have not offered a premise for your assumptions regarding
> the number of queries needed.  An effective proponent would not resort
> to personal berating to dissuade critics.

You have not offered simulations to establish this claim.

All you have done is to make a series of claims that I and the
others who have attempted to answer them are barely able to parse,
let alone understand.

If you seriously believe that there is a chance that Sender-ID would 
bring the network down you are going to have to get someone else to 
put the case in a form that I or others can understand.

I suggest that further discussion of this issue is futile until
such time as Doug provides a simulation that demonstrates that
there is a real risk of catastrophe under realistic network 
conditions.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jul 2004 18:58:40 -0700

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 9 Jul 2004 18:50:51 -0700

> > For Sender-ID, the number of DNS queries added if at the should
> > not exceed limits, would be 2000 UDP queries.  The ratio of 
> UDP queries
> > to TCP packets, in this case, goes from 0.3 % to 666.0 % of 
> TCP packets.
> 
> 
> 4. A statement like "666% UDP to TCP ratio" seems to imply 
> that an average 
> SMTP transaction requires 20 DNS UDP packets, but only 3 TCP 
> packets.  Do you 
> really believe it's possible to deliver a message with only 3 
> TCP packets?  My 
> rough guess was at least 14 and usually 20.

Come on, in the real world we send powerpoint slides and word
documents arround. I send and receive emails in the 500Kb to 
1Mb range on a daily basis.

If we assume that only 5% of the emails have attachments thats
2,700-5,000 packets right there.

Doug insists on assuming worst case, in practice Sender-ID is
going to be no more than 3 lookups in 95% of cases.

I really don't think that it is worth continuing this discussion.

If the attack is real expect to see complaints from the large
ISPs and the operators of outsourced spam filtering solutions,
companies like Postini, Frontbridge, Messagelabs and VeriSign.