DKIM Threat Assessment v0.05
...
1. Who are the bad actors? (Characterize them, eg, what
resources do they have?)
Actors, both good and bad, are senders of email. A
"sender" is any agent in the transit path that creates a
message or that moves it towards a recipient.
I believe you're being a bit too all-inclusive with the
phrase "or that moves it towards a recipient", as that
could easily encompass an MTA and MSA. Unless encompassing
them is your intent?
Bad actors create new messages, or modify existing
messages, for the purpose
of asserting an invalid originator, sender or recipient
identity or to add unauthorized or undesired content.
I suggest changing the meaning a bit and rewording thusly:
Bad actors create new messages, or modify content of
existing messages, to attempt to bypass automatic filters
and human recipients. These messages succeed at bypassing
automatic filters by lying about the identity of the
sender.
I'm trying to describe the simpliest anti-spam mechanism,
which is a whitelist of valid recipients. I'm well aware,
as is everyone else, of the limits of a whitelist, but it
is the basis for automatic whitelists, heuristics, Bayesian
filters, and other mechanisms that attempt to classify
messages and message content in the absense of a long
whitelist and in the absense of strong identity.
Until we have a standardized reputation system, describing
how DKIM could help whitelists be more valuable is probably
the best thing to describe in IETF.
-d
They are able to generate messages on large
numbers of compromised machines, using the identities of the
machines' owners,
without the knowledge or consent of the owners. Alternately,
bad actors may
instead use any other identity they wish, such as for a
well-known transaction
service. Bad actors may set any email envelope or content
header field to any value they wish.
For any email, the recipient might view the author or
sender as a good or bad
actor. That is, they might want to receive the message or
they might want not to
receive it, according to criteria specific to that recipient.
Nonetheless,
there are classes of mail that are commonly assessed to be
unacceptable. The
two major examples -- and they overlap -- are:
a. Spam -- unsolicited bulk email (UBE), and
b. Forgery -- messages that state false
authorship (Joe Job) that
might be known to the recipient, and might attempt to trick
the recipient into
disclosing private information (Phishing).
Hence, problematic mail divides between large quantities of
generally undesired
content, and *any* quantity of fraudulent content.
In the current Internet Mail environment a mail receiver can
never be sure
whether a piece of mail was from the purported author they
normally associate
with the claimed identity. This leads to many avenues of abuse.
In large quantities, undesired messages reduce the utility of
email. Hence, the
primary threat of spam is its volume. By contrast, even in
small quantities,
phishing messages can be extremely damaging.
Therefore, being able to discern undesired mail can be
extremely useful.
Similarly being able to discern desired mail reduces the
impact of the UBE
undesired mail, since it can define a more "trusted"
partition of email traffic.
In these cases, reliable and accurate identification of an
actor claiming
responsibility for the message permits assessing their
acceptability and,
thereby, the likely acceptability of the message content.
DKIM provides identification of an actor associated with the
message. Given that
association, an assessment of the actor can be made.
2. Where do they fit into the protocol environment (eg,
middle of net)?
Most of the relevant bad actors create new messages. Some
of them modify
existing messages, by being in their transit path.
3. What are we trying to prevent them from doing?
The primary goal of DKIM is to distinguish mail that has
an accountable
identity associated with it, from mail that does not. Given
an accountable
identity, an assessment can be made, using reputation and/or
accreditation
ratings.
Accountability is a general benefit, used to prevent
problems, detect
problems as they occur, and to investigate problems after they occur.
A secondary goal of DKIM is to validate a standard
identity field, such as
RFC2822.From or RFC2822.Sender.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim