On Wed, 2004-06-23 at 01:58, Matthew Elvey wrote:
On 6/22/04 8:37 PM, Douglas Otis sent forth electrons to convey:
...
Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack. Introducing a required series of DNS queries to
establish permissions increases a data footprint, but also code size may
also adversely impact system resources depending upon OS and structure.
If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities. The
less rigid and more extensible the syntax, the greater the
vulnerabilities. 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.
As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size. If using the SPF/CID 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.
...
My mail server already checks over a dozen RBLs, plus doing Razor, DCC,
and slews of header and body regexp checks. If MARID is effective enough
for long enough that most spammers give up, then ....
Unlike these queries in parallel to _known_ servers, the SPF/CID schemes
involve a series of queries to _unknown_ and possibly hostile name
servers. The SPF/CID _may_ be effective against some false
representations, but expect these mechanisms to just change the mode of
this fraud. Don't expect SPF/CID to reduce levels of abuse. These
schemes fail to stop rogue systems dumping volumes into the channel. In
addition, any assurances offered recipients will only bolster fraudulent
claims. Expect such fraud to happen more often when channel checking
becomes depreciated due to constant attacks. Now those defrauded have
cause against those providing false assurances.
This will be more realistic:
As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size. If using the SPF/CID 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 4 queries with an average of 1 second
a query, then this limits each process to about _ message about every
minute.
These are messages from hostile domains. Where is there a 4 query limit
to fully resolve permissions?
These 4 queries will also add to the traffic at 50 bytes per record a
total of 0.2K bytes of additional traffic for a halving of the network
load.
In addition to this estimate ignoring the actual size of the query
response, this tread is discussing a requirement that the MTA _MUST_
accept large results even if the information contained is unknown. This
was to allow "new" features added at 100 bytes a whack at the whim of
vendors.
The mail server may normally handle 1,500 simultaneous processes,
but at 4 seconds per process, the mail server has spare capacity up to
'only' running 4000 messages a second.
This may be a typical baseline before being taken down to 25 messages
per second by the attack scenario previously described.
<snip>
Also, you're assuming there are no DNS cache hits.
The cache may be invalidated by small TTL values as stated in the mode
of attack. If not, what is the typical cache size and how many entries
are typically supported in the DNS cache? Causing a flood of 350 byte
responses into the DNS cache will impact more than just mail service.
At 250 per second as described, a minute of such may consume 10 M bytes
of DNS cache. This assumes there is a local caching name server and
results are not isolated to individual processes.
Also, if an SPF query starts with a blacklist check of the domain and
that fails, then no further queries will be made. That's efficient.
But yeah, spammers trying to gum up the works will result in what you're
talking about.
If to assure the recipient of the sender's identity, Fenton's Identified
Internet Mail proposal stops identity fraud with two determinate queries
where fraud is truly curtailed without changes to SMTP. The added
overhead for the Fenton proposal is about 600 bytes carried mostly in
the SMTP and HTTP stream, where DNS simply returns a single SRV record
pointing to the key server. Fenton's scheme has a chance of working and
can isolate efforts for critical communications rather than across the
board. In addition, it would be reasonable to trust assurances offered
by the Fenton proposal. That must not be said of the SPF/CID proposal.
As an RBL check against the address of the MTA is the primary protection
scheme, not SPF/CID, requiring a single query for an SRV record to check
the EHLO domain would allow greater assessment and better protections by
then also enabling RHSBL. This would also enable enforcement efforts
against abusers, unlike abuse sorted by users with the SPF/CID
proposals. SPF/CID fails to assert an accountability claim by the mail
sender. This leaves the door open to abuse unabated.
-Doug