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 [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
