[ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

[Andrew Newton]

Dave,

My comments are in-line:

On Aug 1, 2005, at 6:13 AM, Dave Crocker wrote:
> By way of seeding discussion, here is a feeble attempt (ie, my own)  
> at creating
> a draft response.

Don't sell yourself short.  I don't think I could do any better, and  
by the looks of it most people on this mailing list aren't even trying.

> DKIM Threat Assessment v0.05

I'm a little lost.  I see messages marked with 0.06.  Is there a  
later version?

> DKIM authenticates a domain name identifier, using a digital  
> signature over a
> message body and associated, selected message header fields. It is  
> intended for
> use during message transit.  In typical use, signing (creating the  
> signature) is
> expected to performed within the administrative environment that  
> creates the
> message content and/or that posts it into the transit service, and  
> validating
> (evaluating the signature) is expected to be performed within the  
> administrative
> environment of a recipient.
>
> 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:

In general, I do not think we should be talking about the bigger spam  
problem.  From my observation of some of the dissent at the BoF, I  
think this was giving some people heartburn.

>         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).

The same goes for the larger class of phishing.  End the sentence at  
the comma.

> 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.

While I agree with what you are saying, perhaps the "big picture"  
view should be in an addendum or trailing section.

> 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.

In the protocol environment, bad actors who create new messages do so  
at both message submission points and message transmission points.   
Those modifying existing messages, do so at message transmission  
points.  Did I miss the meaning of your second point?

I don't know how to say this or whether it should be said, but we  
aren't attempting to guard against hijacked SMTP sessions, etc.

> 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.

I agree with this, but I wonder if the part about reputation and/or  
accreditation might be too entangled in the statement of the primary  
goal.  To me, it is one of those bigger picture items.

>    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.

-andy