Review of draft-fenton-dkim-threats-01

| Comments (1) | TrackBacks (7) |
This document reads much more like an analysis of DKIM than it
does like a threat analysis of the environment in which DKIM
will be deployed. There's a subtle but real difference here.
Consider, for instance, Section 5.2.3 says:

   Reputation attacks of this sort are sometimes based on the
   retransmission (often referred to as a "replay") of a legitimately
   sent message.  DKIM provides little protection against such acts,
   except that the key used to sign the original instance of the message
   can be revoked.  Other reputation attacks, involving the fabrication
   and transmission of a fictitious message, are addressed by DKIM since
   the bad actor would not, without inside assistance, be able to obtain
   a valid signature for the fabricated message.

Now, it may be true that DKIM doesn't address this issue, but it's
certainly possible to address this issue (arguably well or badly)
in a message origin signature system. 

What I would have expected in a threat analysis of this type is that
one would start with a relatively broad view of the type of system
one was considering developing ("server-based message-based signatures
to prevent mail forgery") and then describe potential attacks on
such systems and the types of countermeasures that can be used to
protect against them. What I see here assumes that the system to 
be developed is essentially DKIM and asks how DKIM can be attacked.
That's only somewhat useful for determining whether DKIM should be
standardized and not at all useful for determining whether alternative
designs would be inferior or superior.

A related issue is the focus on forgery as the end-goal. The reason
that people are interested in stopping forgery is that they
believe that that can be used to block spam (see Section 2, where
this is explicitly stated). Indeed, if what you wanted to do
was stop message forgery as a general case, you would have to
consider the issue of forgery by other authorized users in
the same administrative domain, which generally leads to an 
S/MIME style solution. What motivates this particular design is
the spam application and I think that that requires a real argument
that this approach will be useful in stopping spam, not just
saying that stopping forgery is good and this stops forgery, so....

S. 1-3:
These sections do a pretty good job of laying out the basic
threat environment. 

S. 4.3:
   Bad actors may also exist with the administrative unit of the message

S 5:
   One of the most fundamental bad acts being attempted is the delivery
   of messages which are not authorized by the alleged originating
   domain.  As described above, these messages might merely be unwanted
   by the recipient, or might be part of a confidence scheme or a
   delivery vector for malware.

This seems to me to be too concrete. At a meta-level, the bad
act being attempted is the delivery of messages which the receiver
doesn't want to see (see Section 2 again). What's the necessary
connection between that and sending forged e-mail?

S 5.2.1:
Note that some such e-mail propagated worms
really did come from the person who they claim to come from,
because that person's computer has been taken over.

S 5.2.2:
Well, it's certainly true that much e-mail based fraud involves
forging the sender address, it's not clear that this kind of
forgery protection will help. Consider how a typical phishing attack

(1) attacker sends forged mail from
    This message contains a link to
(2) Victim clicks on link. Note that this is can be an SSL link
    with at least a semi-legit cert.

This attack works because the victim doesn't do a sufficiently good job
of checking that the URL that he's connecting to actually corresponds
to the site he thinks he's connecting to. 

Now, in an environment where DKIM is deployed, the situation would
differ in that From address in the mail would contain

Now, in theory, of course, the user might notice that the From
address was wrong, but since the entire attack is premised on the
notion that he doesn't adequately check the URL in the browser
location bar, why should we expect him to do a better job of 
checking the From address?

This is acknowledged to some extent in 5.2:

   Similar types of attacks using internationalized domain names have
   been hypothesized where it could be very difficult to see character
   differences in popular typefaces.  Similarly, if was
   controlled by a bad actor, the bad actor could sign messages from which might also mislead some recipients.  To
   the extent that these domains are controlled by bad actors, DKIM is
   not effective against these attacks, although it could support the
   ability of reputation and/or accreditation systems to aid the user in
   identifying them.

But doesn't this effectively say "DKIM (or any sender signing scheme)
doesn't work against attacks that attempt to involve impersonating
a specific source address"? What class of specific impersonation
attacks does this technology actually work against in practice?

S 5.2.3:
I don't see how you can reasonably deal with replay attacks
by revoking the key that was used to sign the message. This
enables a trivial DoS attack on any message sender--just
get some messages from that sender and generate some replays.

S 6.3:
Again, I realize that the DKIM designers have chosen not to
handle replay, but that doesn't mean there's no way to handle
it with a server-based signing scheme. This seems like exactly
the kind of issue that a threat analysis should cover.

7 TrackBacks

Listed below are links to blogs that reference this entry: Review of draft-fenton-dkim-threats-01.

TrackBack URL for this entry:

beach babes anal dildo beach babes comics black babes free private voyeur... Read More

free online blackjack from free online blackjack on November 17, 2005 8:03 AM

You may find it interesting to visit some relevant information about internet blackjack blackjack rules Read More

generic viagra from generic viagra on November 21, 2005 5:25 AM

determines framed:decomposition premises rifled viagra Read More

Depression Read More

Free Ringtones from Free Ringtones on January 20, 2006 6:09 PM

Free Ringtones Read More

Home Equity Loans from Home Equity Loans on February 3, 2006 10:44 AM

Home Equity Loans Read More


DKIM does nothing against spam. Anything in the document that says otherwise is pure wishful thinking. A spammer can buy a domain name for a nominal price, set it up with DKIM signatures,
and emit all the mail he likes. Even with other reputation-based heuristics (time domain has been registered, etc.), the advantage is very, very small, because the spammer that knows the heuristic can tailor behavior to look legitimate.

It may help joe-jobs, but the improvement is marginal, for the social attacks noted above.

No panacea here, and the effort involved is higher than the reward, in my personal opinion.

Leave a comment