Subject: [ietf-dkim] RFC 4686 on Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

From: [email-masked]
Date: Tue, 26 Sep 2006 18:02:10 -0700

A new Request for Comments is now available in online RFC libraries.

         RFC 4686

         Title:      Analysis of Threats Motivating DomainKeys
                     Identified Mail (DKIM)
         Author:     J. Fenton
         Status:     Informational
         Date:       September 2006
         Mailbox:    [email-masked]
         Pages:      29
         Characters: 70382
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-ietf-dkim-threats-03.txt

         URL:        http://www.rfc-editor.org/rfc/rfc4686.txt

This document provides an analysis of some threats against Internet
mail that are intended to be addressed by signature-based mail
authentication, in particular DomainKeys Identified Mail.  It
discusses the nature and location of the bad actors, what their
capabilities are, and what they intend to accomplish via their
attacks.  This memo provides information for the Internet community.

This document is a product of the Domain Keys Identified Mail
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body

help: ways_to_get_rfcs. For example:

         To: [email-masked]
         Subject: getting rfcs

         help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Sep 2006 07:40:16 +0100

Well done to all concerned, esp. Jim of course!
S.

---

From: Damon <[email-masked]>
Date: Wed, 27 Sep 2006 13:41:05 -0400

All the threat listed in the document require some sophistication on
the part of the spammer. Would this mean the end of the "basement"
spammer if widely deployed? I also see (not listed in the document) a
long deployment time a threat. Notice that spammers were the first to
jump on the SPF band-wagon and made their domains SPF compliant. Some
people pointed to this as an SPF failure and asked themselves what the
point was to deploy it. This caused the "garage" spammer to live on.
Hopefully this document does not raise the question "What is the point
of deployment?" but is used, in part, to show the hoops that spammers
will have to jump through. Any time you make it more difficult (and
therefore more costly) for a spammer to spam, you start to thin out
the players.
Just food for thought.

Regards,
Damon Sauer

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 28 Sep 2006 04:31:25 +0200

Damon wrote:

> spammers were the first to jump on the SPF band-wagon and
> made their domains SPF compliant. Some people pointed to this
> as an SPF failure and asked themselves what the point was to
> deploy it.

If spammers publish policies resulting in either PASS or FAIL,
and send MAIL FROM such domains, it's fine.  If other domain
owners don't see the point now they'll see it later if their
domain is forged... <shrug />  They can also check out BATV
in constellations where that's possible - but that won't help
receivers flooded with alleged MAIL FROM that domain.

> Hopefully this document does not raise the question "What is
> the point of deployment?"

Of course it does.  A DKIM SIGNED isn't the same as SPF PASS,
because the latter at least indicates that bounces won't hit
innocent bystanders, but otherwise spammers will try to get a
DKIM SIGNED like they try to get an SPF PASS.

If some folks then whine that DKIM is pointless because smart
spammers (try to) deploy it... <shrug />  The real question is
if legit senders and more important receivers deploy it - and
for what purpose, simplifying abuse reports isn't too exciting.

Frank