ietf-mxcomp
[Top] [All Lists]

Will SPF/Unified SPF/SenderID bring down the 'net?

2004-06-28 09:55:37

Removing spf-discuss(_at_)v2(_dot_)listbox(_dot_)com from the cc list; they're not going to abandon their scheme, and they can't address these issues without doing so; the right place for discussion is therefore MARID.


On 6/27/04 3:15 PM, Douglas Otis sent forth electrons to convey:

Matthew,

This was in regard to an attack scenario with motivation given for such.
Surprisingly, you base performance using known servers for your best
case scenario.  In addition, estimates for a DNS response from the the
TXT record query must include the size of TXT record with another 56
bytes and the size of the name referenced.  I put together what I
thought could be considered a reasonable set of circumstances allowed by
the draft. I did not take this to an extreme. I wanted to illustrate difficulties identifying these attacks with their potential impact on
performance.
Yes, I would like to confirm that I think your scenario is more than reasonable: it represents a likely scenario at some point, should SPF be the base of MARID.

Even if there are messages processed quickly, the slower messages will
very much dominate the load on the servers.  As SPF allows open lists,
these attacks may never reference any domain or name server owned by the
attacker.  Should this attack be distributed to many destinations, then
the name servers should be expected to become erratic where this will
help sustain the attack.
Sender ID, IIRC, at least suggests that SPF records that require > 20 queries to resolve are inappropriate. SPF should adopt this, or something stronger, as well (it says something more vague). Even if this was adopted, the DDoS exposure is large.

SPF never directly establishes the domain accountable for the mail
stream.  As a result, finding a method of stopping a flood of abusive
mail must depend upon methods outside of the SPF.  Identification
methods available to commerce and advertising could implement the Fenton
"Identified Mail" proposal without jeopardizing mail services and this
completely guards against identity fraud.  SPF interferes with the
normal use of mail as well as the Fenton proposal in that it attempts to
tie identity to the mail channel.  CSV on the other hand protects
against abusive domains without increasing risks from attack and leaves
the use of mail unchanged.  CSV allows follow-up should there be
criminal fraud and allows policy evaluation of the domain handling the
mail.

The types of information gleaned from SPF and CSV are similar in that
they both identify outbound SMTP servers.  A difference for CSV is that
it is comprehensive in that it limits identity to the domain accountable
for the mail stream, whereas SPF attempts to correlate domains permitted
to carry mail for other domains.  As this SPF correlation is never
expected to be comprehensive, either this list must be defined as "open"
or a method to "usurp" this permission must be allowed.  Either
exception keeps the door open for abuse and fraud.
Can you give an example? I'm not sure I follow. Are you referring to SPF being 'optional', or what?
If SPF is not checked at the channel, then assurances provided the
recipient by the SPF mechanism is highly suspect and provides
motivations for attack. SPF will also likely lead to greater
restrictions on the use of mail addresses and the ability to forward
mail to a common account.  Both of these outcomes will be onerous for
users and providers and again offer motivation for attack.
Not onerous given Unified SPF, which I think you're familiar with. These folks are very unlikely to attack the system. Spammers are likely to attack the system. (Where by attack, I mean not just in the 'argue against' sense, but a real military (e.g. DDoS) sense.)

CSV does not change the way mail is used and, for most users, they will
only notice a reduction in abuse as it can quickly identify infected
systems.  Unlike an address method of vetting a sending SMTP client, use
of a domain name allows a greater history to be acquired, even where the
address may be dynamically assigned or shared and allow assertions of
affiliations.  Vetting a domain name that handles the mail allows
greater speed and accuracy as opposed to only an IP address.
If it turns out that SPF adoption leads to significant network harm, then it would be possible to tweak it or replace it with something more effective, with narrower scope, in particular CSV. This is a valuable discussion. Let's flesh out more your attack scenario, so we can be proactive about this. I could see SPF causing some free DNS providers to go belly up. OTOH, DNS is a remarkably efficient protocol, so perhaps SPF is sufficiently lightweight. It seems that traditional BLs were near the tipping point- concerted DDoS attacks brought down some BLs, but were unable to take down others. MARID should be more stable than that. I think we may need to wait for Unified SPF to become an I-D; it's difficult to flesh out its DDoS exposure right now. I suspect it is more resistant.


<Prev in Thread] Current Thread [Next in Thread>