Subject: [ietf-dkim] Possible exploit of DKIM

From: Thiyaga <[email-masked]>
Date: Sun, 2 Nov 2008 19:13:06 +0530

Hi,

We recently decided to implement DKIM in our organization.

While reading through the RFC, I found a possible case, where the
authentication is lost.   (Sorry if it is already discussed and a known
issue)

Scenario:
Let's assume a spammer wants to spam email accounts on domain "X.com" and
the spammer uses a domain "Y.com". Both the domains have implemented DKIM.

1) For example, Spammer can create accounts in X.com & Y.com like
[email-masked] & [email-masked]

2) From [email-masked] the spammer can send a spam mail to
[email-masked] adding it in BCC and the mail is digitally signed. Let's
assume the mail is delivered to [email-masked]

3) Now spammer can take all complete headers and body from
[email-masked](including signature header) and he can send them to
all possible accounts
on X.com from botnets and not necessarily from Y.com
Note: Delivered mail won't contain "To:" header as the address was added
in BCC -- as mentioned in point (1)

However the above procedure has some cost -- Spammer has to create a sample
account on a domain (say X.com) to spam most of the accounts on that domain
(X.com). But the cost is very less -- advantage of spamming most of the
accounts by just creating a *sinlge* account.

Mail once signed can be used forever to spam others -- by making it to arise
from different botnets and giving an illusion that the botnets actually
signed a mail. Here DKIM fails to detect it and passes the mail completely.

One possible simple solution/suggestion:
- At outbound MTA add IP which is going to send mail along with the
signature (in some format) before encrypting.
- In inbound MTA decrypt the value and check if the mail arised from the
corresponding IP in addition to checking the signature.

The above suggestion would break, if a mail is forwarded by a domain on
behalf of some other account. But it has a work around by checking the
IP/Domain with the sender's domain.

Please let me know your comments. Sorry again, if it is already known and
discussed previously.

Thanks,
Thiyaga
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Sun, 2 Nov 2008 10:16:21 -0500 (EST)

> the spammer uses a domain "Y.com". Both the domains have implemented DKIM.

This looks like a standard replay attack.  Such technique can't be
used to send SPAM on behalf of domains that don't sign SPAM (e.g.,
porcupine.org).  If a domain is willing to sign SPAM, then they
deserve that all their messages are handled with great prejudice.

It is possible to take DKIM-signed messages with signature and all,
and to append SPAM at the bottom, but that is not a very effective
way to reach many eyeballs.

	Wietse

---

From: Thiyaga <[email-masked]>
Date: Sun, 2 Nov 2008 23:01:50 +0530

Hi Wietse,

Thanks a lot for your comments!

> deserve that all their messages are handled with great prejudice.

Yes, I agree. It can't be used to send SPAM on behalf of domains that
don't sign SPAM.

But if it signs SPAM unknowingly (which may happen in large ISPs --
where few mails get slipped through spam checks), then it creates a
potential loop whole that lots of duplicate SPAM mails can arise out
of it. A spammer can specifically target/exploit this behavior. It
creates the vulnerability of sending SPAM mails with DKIM signed on
behalf of the same domain -- even *without* the knowledge of that
domain by sending through some other spammy domains or botnets!

Is there any reason, why we didn't take any possible action/solution
to this issue? If the solution is simple (like the one I mentioned in
my previous mail -- adding outbound MTA's IP or Network to signature),
we could easily make DKIM resilient enough to such attacks and loop
wholes? Please advise.

Thanks,
Thiyaga

---

From: [email-masked] (Wietse Venema)
Date: Sun, 2 Nov 2008 13:16:05 -0500 (EST)

> But if it signs SPAM unknowingly (which may happen in large ISPs --

If a domain is willing to sign SPAM, then they deserve that all
their messages are handled with great prejudice.

DKIM provides domain-level signatures. It is not a replacement for
user-level authentication systems such as S/MIME or PGP.

	Wietse

---

From: SM <[email-masked]>
Date: Sun, 02 Nov 2008 10:56:10 -0800

>domain by sending through some other spammy domains or botnets!

See Section 8.5 of RFC 4871.

>we could easily make DKIM resilient enough to such attacks and loop

If DKIM was tied to the outbound's MTA IP address, it would face the 
same problems as SPF when it comes to forwarding.

The goal of DKIM is to permit a signing domain to assert 
responsibility for a message.  If the signing domain is concerned 
about its reputation, it should avoid signing messages which may be 
viewed as spam.  The signer may set a signature expiration to limit 
replay attacks.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 02 Nov 2008 12:00:03 -0800

> same problems as SPF when it comes to forwarding.

For those who have been around DKIM for awhile, this thread will no doubt look 
quite familiar.

If someone will writeup a thorough response to this oft-expressed concern, I'll 
post it in the DKIM FAQ.  (I suggest running it past the list, to get some 
agreement on the details.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Thiyaga <[email-masked]>
Date: Mon, 3 Nov 2008 22:10:05 +0530

Thanks all for your valuable comments!

-Thiyaga-

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Nov 2008 17:33:52 -0800

On Nov 2, 2008, at 10:16 AM, Wietse Venema wrote:

>> Yes, I agree. It can't be used to send SPAM on behalf of domains  
>> that don't sign SPAM.
>>

I do not agree.  As long as the "on-behalf-of" field within the DKIM  
signature accurately reflects what a domain authenticates when  
accepting a message for signing, then only messages signed with that  
identifier should be at risk of becoming blocked.

A large ISP's domain is unlikely to find the entirety of their  
messages blocked.  This is why ADSP is so destructive.  ADSP impairs a  
domain from always asserting an accurate "on-behalf-of" field whenever  
the identity differs from what is found in the From header.   ADSP  
should have been defined to only require a signature from the domain  
of the From header and not require the use of  an Author Signature.

> user-level authentication systems such as S/MIME or PGP.

Agreed.  Which is why the DKIM signature should not be forced to be  
"on-behalf-of" the From header field!   Any DKIM signature should be  
able to assert opaque identities only understood by the signing  
domain.  DKIM is _not_ about assuring the identity of the author as  
ADSP pretends.

-Doug