On Jun 26, 2008, at 3:09 PM, Frank Ellermann wrote:
Douglas Otis wrote:
This provider publishes SPF records
What a vague description, do they also publish WKS or MX records ?
I trust that this has nothing to do with DKIM.
The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.
Although Sender-ID allows an override by version 2, it imposes the
same risks, and is not used in this case.
The relevant concern is whether a bad actor can influence the PRA to
take advantage of SPF macro expansion capabilities to source an attack
using transactions expanded from cached SPF records. Distributed
attacks would be initiated by the evaluation of messages sent by
exploited providers. A bad actor's PRA/SPF record might link to an
exploited provider's record or simply have the provider's CIDRs
appended. Not only can bad actors stage an attack using little of
their own resources while also spamming, they also enjoy an enormous
unblocked connection. Of course, bad actors would also have their
messages receive a Sender-ID and/or MAILFROM PASS authorization. :^(
the PRA is not restricted.
That could mean that they have no spf2.0/pra (or similar) policy, or
if they have it that there is no chance to get a FAIL for any
sending IP, or if there are FAILing cases, that some IPs could
result in NEUTRAL, for values of some up to "almost all".
Version 2 records are not present. A bad actor's messages can receive
PRA PASS authorizations even within tightly constrained provider
address lists.
a recipient of their message might be convinced to process perhaps
nine macro expanded SPF records evaluating a PRA targeting some
victim
A policy of an ordinary provider won't "target some victim". A chain
of nine "include:" or "redirect=" records eats up nine of ten
directives permitted to trigger additional DNS queries.
A customer's message determines the PRA in various ways where macros,
rather than DNS records directly, might do the bulk of the damage.
Unfortunately, the situation could be worse for DKIM.
To get any "victim" in this scenario the policy has to use nine
"include:victim.example", which might be an attack or stupidity.
Because your description was about an ordinary provider "attack" is
out, so tell them how to get it right, with a copy to
abuse(_at_)victim(_dot_)example
A bad-actor able to influence the PRA would be able to induce a series
of transactions against a victim from a cached SPF macro expanded
record. Freedoms allowed in the construction of a message thereby
become exploitable. Freedoms are lost due to Sender-ID exploits. The
macro capability found in the SPF record can cause recipients to
construct a set of transactions targeting a victim domain that is
unrelated to any domain seen within the message. For the bad actor,
the additional cost to stage the attack is miniscule.
Although DKIM does not have a macro expanded records, the number of
identities a bad actor could influence represents similar risks. For
this reason, those using DKIM may soon need to consider strategies to
deal with this issue, depending upon who becomes the target of
course. The slight change to the definitions in the otis-dkim-adsp
draft is aimed at ensuring a means to facilitate an anti bot-net
effort without requiring additional signatures or identities. A
requirement for multiple signatures or identity structures would be
heading in the wrong direction. In addition, these changes make DKIM
signatures generally more secure. The concept behind the change is to
permit a domain to always directly sign a message with an on-behalf-of
identity that reflects either the author, or opaquely, an account.
The TPA-ADSP extension allows a single transaction to provide the same
authorization flexibility enjoyed by Sender-ID (which may require many
transactions), but without path registration issues, key exchanges, or
domain delegations.
Some people in the WG seem to have difficulty accepting that DKIM/ADSP
is not about making strong assertions of the author identities. This
resistance can be easily seen when comparing this draft to SSP-03.
DKIM is about allowing the domain to demonstrate their role. In the
case of ADSP, it is the Author Domain and not the Author being
evaluated. It is up to the Author Key Domain what gets signed and on
who's behalf.
The problem that SPF sans Sender-ID hoped to solve is more safely
handled by adoption of RFC3834.
Actually the problem tackled by RFC 4408, i.e. backscatter, would
defeat the core of 2821bis, RFC 3834, and RFC 5230, where it is not
solved. As nothing else offers a general solution - ignoring the
obsolete reverse routes in STD 10 - everybody is free to use a
crystal ball or SPF to judge an envelope return address, as the
known precondition to make 2821bis and RFC 3834 work as designed.
Disagree. RFC3834 allows content of the message to be eliminated in
most cases. Such elimination removes incentives to exploit those
willing to issue DSNs. Of course diagnostic information should be
included to offer some insight as to the reason, such as policy, size,
or incompatible format etc.
And I'd wish that one of my providers would at least use a crystal
ball instead of accepting fake bounces allegedly from
postmaster(_at_)my(_dot_)provider(_dot_)example
with ZIPped worms => not all rubbish requires SPF, a minimal IQ can
also help.
Had this problem been dealt with by the IETF instead of closing the
WG, what remained would likely have meet most of your expectations
safely. Except of course this might not be the same for someone who
expected forwarding to still function as it had. : )
A reputation service could help make that happen.
In that particular case I fear they'd end up with "it is from me, I
trust me", and continue to dump the worms in my mailbox. SpamCop
always informs me that the open proxies are known. Stupidity is
certainly a major factor wrt mail.
Some may consider a DSN that does not adhere to RFC3834 and that
includes the original spam to be treated as if the client originated
the message when deciding what goes onto temporary blocking lists.
For us, this would likely require a portal selection to allow each
domain a means to make this decision for themselves. There are
several schools and large organizations that have had their valid
recipients lists discovered and heavily exploited, where even SPF and
filtering fails to offer a level of relief they had hope to obtain
with respect to DSNs. Perhaps a slowly changing BATV or something
like a TPA extension that covers the MAILFROM might eventually offer a
solution, especially when domains adhere to ADSP requirements.
Folks could manage to decorate open proxies with a PASS :-( But at
least any bounces would then hit the stupid party.
We are still giving bad actors more bullets while also ensuring our
hands are tied and our eyes are blindfolded. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html