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