On Mon, 1 Aug 2005 12:13:10 +0200, Dave Crocker wrote:
* Who are the bad actors?
* Where do they fit into the protocol environment (eg, middle of net)? *
* What are we trying to prevent them from doing?
So far, most of the follow-up on the draft threat analysis thread has been
about
my initial paragraph that summarizes what DKIM does, or the last paragraph
about
decoupling from existing identity fields. What has been almost completely
absent from followup discussion has been a discussion about the threats that
DKIM is responding to.
Dan Wing's posting <http://mipassoc.org/pipermail/ietf-dkim/2005q3/000036.html>
was a notable and constructive exception. That he challenges (disagrees with?)
some of the draft text is dandy, since he suggests alternative text, pointing a
path for group discussion and maybe even resolution.
Can we please get more discussion of the type he is attempting?
In the hope of helping folks focus on the requirement at hand -- reaching
agreement on a threat analysis -- here is the text again, minus the distracting
first and last paragraphs.
d/
ps. I consider the answer to question #3 to be quite weak. Not that it is
wrong, but merely that it is thin, and probably that it is incomplete.
- - - - - - - - - -- - - -
DKIM Threat Assessment v0.06
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.
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. 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.
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