ietf-asrg
[Top] [All Lists]

[Asrg] Re: 100:11

2007-02-09 19:21:43
Douglas Otis wrote:
 
There are also TXT records that may accompany the A record.
Often this indicates a contact method.

If you're talking about TXT records accompanying DNSBL listings
they're generally URLs, the exp= in SPF is a similar idea.

Whatever gets used must be robust against DDoS attack without
costing a fortune.  Other solutions might be more effective,
so why rule them out.

URLs are fine, they work for everybody, and you don't need I18N
considerations for http, it's a solved problem.  I'm a "whois" 
fan, but there are cases where "http" has a few advantages.

Comparing the size of the message with the size of the final
queries is bogus.
 
The attacker is sending spam anyway.  Even email traffic should
not be considered part of the attack overhead.  This means the
amplification is actually much much greater!

No, it means you've to compare queries answered by the attacker
with queries sent to the victim.  And that's a factor 9 with mx-
mechanisms in SPF, no matter what the attacker does.

The SPF macro language allows the same SPF script to utilize
local-part elements of an email address

There's no such thing as "SPF scripts".  You've enumerated the
macros in your PDF, they're all derived from the input IP, the
checked address, and the HELO identity.

The PTR stuff might appear to be a bit obscure, but actually it
is what any MTA checking reverse DNS does, once per session.
And completely unusable for any kind of attack.

The MX records and their targets then enjoy the difference
between a negative cache TTL

Whatever they enjoy or not, there's a limit of ten names per
MX record in SPF evaluations.  With different local parts the
attacker can cause queries to different bogus MX records on
his own server (per mail).  So he got rid of 1 of 11 queries
sent to his own server, if it's the same cached SPF policy.

He still has to answer the ten MX queries, each with 10 names
in the domain of the victim.  But in your PDF you say a*b*c*d,
one of that is used local parts, another is recipients per
mail.  With an assumption that all recipients check SPF at
their MUA, clearly against a recommendation in RFC 4408.

Ingnoring that - the number of local parts and recipients is
still irrelevant for the amplification of at most 10 queries
per MX.  The attacker can drop the complete SPF business and
try to abuse "call back verification".

Queries are randomized by the local-part as needed.  Attacking
queries will not be found within an cache.  This is not nonsense.

The "randomized" stuff are mx:%{l}.attacker.example mechanisms,
queries to the attacker.  One of your a*b*c*d factors was the
number of recipients of the same mail, the same local part.

The attacker will still be able to send the same number of
spams, while also completely melting down some targeted network.

While combining spam with DDoS attacks might be a fine art, I'd
pick a more direct approach and try to either spam or DDoS, not
some combo depending on an unknown number of recipients checking
SPF behind their border MX, against several SHOULDs in RFC 4408.

In in the libraries I reviewed, many don't even limit the number
of targets being accessed.  What is a good limit for NXDOMAINs
for SPF scripts?

Evaluation => library.  SPF policies aren't affected by your
convoluted attack recipes, nobody uses ten mx-mechanism each with
ten names, and implementations were always encouraged (SHOULD) to
limit their efforts in addition to the MUST limits.  No working
policy needs to be "upgraded", talking about many non-existing 
names in MX records was and is always a bad idea.

Why not simply authenticate the SMTP client and then associate 
various originating domains?

The recommended SPF HELO check comes before the MAIL FROM checks.

If you don't like the latter you can still do the former, it has
the nice feature to work everywhere, not only at the border.  Of
course receivers could impose their own rules on HELO without
checking what the alleged sender proposes.  But receivers trying
to follow the RFC 2821 rules might like a kind of permission to
be stricter offered in a "v=spf1 a -all" or similar policy.

bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45
ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177
ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22
ip4:69.156.197.234 ip4:66.241.131.163 +all"

A bogus policy, so what ?  Anybody can claim to be HELO bell.ca
or to send MAIL FROM:<whatever(_at_)bell(_dot_)ca>

The goal could be to list the IP addresses being used without
SPF causing messages to be mysteriously lost

SPF doesn't lose mails mysteriously.  A FAIL detected at the
border is simply rejected.  The policy shown above will attract
spammers to abuse bell.ca whereever it pleases them.  If their
goal is to publish obscure lists of IPs they better dont't use
"v=spf1", they could say "our ips" without "+all" at the end.

Executing script from anonymous sources is a basic problem.

Yes, fortunately SPF is no script, although you apparently argue
that MX records are a fundamental security problem.

Frank



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg

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