Re: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)
2005-08-11 13:52:38
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
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim
|
|