Folks,
One of the major directives from the Paris BOF was to develop a clear and
useful
Threat Assessment. Offline, Russ Housely (venerable AD) provided some
guidance,
in the form of 3 basic questions:
* 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?
The threat assessment that was put on the DKIM web page last week primarily
discusses the threats *to* DKIM usage, rather than the threats to which DKIM
*responds*. That makes the document useful, but not what is being requested
from us.
By way of seeding discussion, here is a feeble attempt (ie, my own) at creating
a draft response.
(Disclaimer: calling this feeble is not merely pro-forma false modesty. I have
no reason to view either my insight into the requirements or my draft response
as being particularly accurate. Still, one must begin somewhere...)
You are strongly encouraged to suggest changes or even wholesale
replacement.
I further strongly urge folks to minimize debates about "concepts" and,
instead, to emphasize actual draft text to be used that folks can agree
to.
- - - - - - -
DKIM Threat Assessment v0.05
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:
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