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