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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > 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
