On 5/27/10 9:01 PM, Steve Atkins wrote: > There are, I think, two problems that are intrinsic to the use of ADSP in the > context of mitigating phishing email. > > One underlying problem is that ADSP is based on the inverse of an > intentionally unreliable positive assertion (DKIM). That maps the non-problem > of a mail with a broken DKIM signature being treated as unsigned to the > serious problem (72% false positive rate) of mail with a broken signature > being discarded. > > The only reason that DKIM is intentionally unreliable is that it's primary > design constraint was that it would be something that could be added by a > smarthost, without the sending MUA needing to be aware of it, and received by > an MX and delivered to a receiving MUA without either needing to be aware of > it. > > If ADSP were based on a reliable signing algorithm (such as S/MIME) then my > objections to it based on the fragility of DKIM would go away (fundamentally, > that it doesn't work reliably and causes legitimate email to be lost). Given > it's primary value is when applied to B2C bulk mail, the constraints that > apply to DKIM signing wouldn't apply and pretty much every MUA renders S/MIME. > > While I believe that would be a much smarter direction to go in, we've chosen > not to. As ADSP is based on DKIM, and DKIM is always going to have a > significant level of broken signatures, ADSP is always going to have a > significant false positive rate - making it unusable for mail that it's > important be delivered. > One objection to S/MIME was its poor presentation, where a failure as appearing to be phish is less tangible. S/MIME is also not compatible with provider practices of modifying presentations. In this case, the provider is expected to track its own brutal message handling, the motivation for Authentication-Results headers. Providers often consider themselves responsible for a user's impression of a message. Adding virtual icons, colored borders and the like can be effective strategies at combating phish, where presentation plays a critical role not compatible with S/MIME. > All we can do is mitigate in an attempt to reduce that false positive rate. > I'm sure we can come up with something that'll bring it down to single digit > percentages of legitimate mail lost, or even to less than 1%, at least in > some cases with very limited use of email (bulk mailer smarthost directly to > major ISP MX, for instance). And there are situations where the mail that's > being sent is sufficiently worthless or redundant that losing one mail in > every few hundred might be acceptable. > > The other underlying problem, as applied to phishing email, is that ADSP will > currently, if implemented perfectly by all senders and all receivers, reduce > the volume of phishing mail delivered to the inbox by less than 50%, and that > reduction is likely to decrease rapidly. Given the volume of phishing mail > sent, and the volume of it that's already blocked much more reliably by > existing filters, that means it is likely to have minimal effect on the > number of phishing emails delivered to the recipients inbox. > This conclusion overlooks the role message presentation plays. A role that represents a highly effective deterrent. > So the suggested use model is one where the security of the mail is so > critical that it's worth going to this much effort in order to discard<50% of > phish messages, yet it isn't critical enough that losing one in every few > hundred legitimate messages isn't a problem. This doesn't seem like a use > case most informed security or bulk email experts would consider interesting. > If that's the low bar we're aiming for, then we're fine, but it would be > dishonest not to document the limitations in a way that's clear to even a > casual reader. > Where signatures are damaged beyond the provider's control is where attention is needed. This often represents third-party services.
There are two possible approaches for handling these services. A) Have senders publish, in a scalable lightweight fashion, which third-party services are used. B) Depend upon recipient funded services that assess these services. Organizations most affected by fraud should be able to easily comply with A. In the case of public domains where fraud is less of an issue (ignoring successful ploys that leverage social networking) then B is needed. The third-party authorization scheme suggested can handle either approach. In the case of B, DNAME could vector to a consortium policing these services by publishing their own list of acceptable domains. These services will likely specialize on handling different regions. The suggested third-party authorization scheme attempts to include several qualifiers to further limit acceptance where possible, such as requiring LIST-ID, or authenticated Mail-From. It seems that this should be kept flexible, until it become understood what is needed. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
