On Mon, 2004-06-28 at 09:55, Matthew Elvey wrote:
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.
CSV and then SPF if at all. I should also note to assess traffic caused
by these queries, the byte count should also include Ethernet (26), IPv4
(20), and UDP (8) overhead for an additional 54 bytes.
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.
Yes, but sadly Sender-ID never ensures accountability to enable
repudiation services a means to stop abuse. Sender-ID leaves the door
open for abuse and thus can never offer protections from any type of
DDoS attack.
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?
SPF does not identify the domain injecting the mail stream. Nor does SPF
demand lists being referenced by the message domain to be "closed."
This means a repudiation is meaningless if done on "unknown" in the case
the list is "open" and the address of the sending SMTP does not match.
There is no rejection of the message nor an assessment made against a
domain if this message is found to have been abusive. The case of a
domain "usurping" permission in SPF is no different than CSV. CSV
treats all domains in this manner and allows no exceptions. This means
for CSV, only a single query will provide a much smaller and yet
comprehensive block record that has the sole purpose of assigning
accountability irrespective of message content.
There are much stronger and more scalable means to identify the author
of a message such as the Fenton "Identified Mail" proposal. There are
much more dependable means of establishing mail channel accountability
such as CSV. SPF does neither of these functions well, but at a much
great risk in terms of causing return addresses to be problematic and in
creating DDoS attacks.
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.)
There are significant problems using a SPF TXT record for CSV. CSV uses
the HELO domain and not the return path domain. This record must be
specific about the domain sending the mail stream to accurately assess
accountability. Such an assessment is not enabled by the SPF record.
The resolution of the HELO domain will likely require a specific record
label different from that of SPF. I see the SRV record being far more
appropriate for use with CSV for these reasons. If there is to be
"unification," I would hope to see a required channel check using CSV
and then, if there is a desire for "protections" offered by SPF, perform
these SPF checks in parallel but of course using SPF records.
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.
Keep these two specifications separate and apply CSV first for both
accurate repudiations and for the protections needed for the possible
implementation of SPF.
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.
I fail to see how publishing the correlation of users to domains is ever
going to be 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.
I see genuine value in moving CSV forward irrespective of the deployment
of SPF. I see much better ways to identify authors and again point to
the Fenton proposal as how to strongly identify the author without
breaking mail. I expect CSV being a far more effective tool against
mail abuse and a far more effective tool for enforcement.
-Doug