ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] marketing dkim

2010-08-20 13:17:31
Daniel, et al,

Persistent misunderstanding of DKIM is a significant problem, and worthy of 
efforts to make corrections.

To that end:

On 8/18/2010 6:59 PM, Daniel Black wrote:

I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs.

My current plan for a talk is:
* DKIM is a really well developed standard for signing email

As noted, "signing email" is not DKIM's goal.  Attaching a verifiable label 
that 
can be used for assessment is DKIM's goal.  The difference is not merely 
significant; it is fundamental.


* Combined with ADSP=discardable it can filter email at ISP gateways without
too much fear of unduely lost email

The utility of ADSP is not yet established and is clearly controversial.  
That's 
another way of saying that it's utility is risky.


* BUT otherwise its useless in its current state.

1.  It can be used in exactly the same way an IP Address is used, for 
establishing statistical reputation.  Except that it can't be spoofed and it's 
better suited to this task than is a topology-dependent label.  More stable. 
Not shared.  Etc.

2.  It permits attachment of multiple labels, by different actors.  You can't 
really do that in an unspoofable way with IP Addresses.  The benefit is a 
richer 
basis for reputation assessment.

3.  It permits stream differentiation; you can't do that conveniently with IP 
Addresses.

4.  It enables verifiable accountability, such as is already used for feedback 
loop registration.


Costs:
* Product deployment and DKIM training and documentation for staff
* Trying to work out why some outbound streams of email get lost (when there
is no IETF guidance for the receiver)

Researching "lost email streams" (whatever that actually means) is an existing, 
generic cost that has nothing specific to do with DKIM.


* Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02
4.1)

This is not a DKIM problem.  It's an ADSP problem.  As noted, it's important 
not 
to confuse the two.


Benefits:
* A recipient may through good design manage to pass good signatures and drop
bad signatues while allowing mailing list mail through.

This is not a DKIM problem.  Broken signatures are supposed to be treated as no 
signature.


Given likelyhood of benefits are signficantly lower that costs I'm not seeing
a benefit for a signer.

The benefits are significantly higher when the costs and benefits are more 
accurately defined and assessed.


Cost/benefit to verifier:
Costs:
* software deployment training and documentation
* increases concurrancy of email processing waiting for DKIM keys OR post
processing where rejection could result in backscatter.

This one is confusing, but sounds silly.

There's no indication that DKIM processing slows mail down, and there's quite a 
lot of experience processing DKIM mail.  There has also been some direct 
research on DKIM overhead and it was deemed negligible.

If DKIM processing had a significant performance effect, we'd have heard about 
it by now.  But we haven't.


* implement some filtering scheme based on RFC5863

"based on"?  That sounds as if the document specifies filtering schemes.  It 
doesn't.  It discusses them.  The difference is fundamental in terms of type, 
granularity and intended utility of the topic.


Benefits:
* rejecting ADSP=discardable messages with missing or broken signatures

Whether that is actually a benefit is not yet established, particularly since 
we 
already have demonstration of false positives due to signer errors.


* Adding AR headers (that a user or their MUA may never work out how to use
effectively)

There is no particular intent and certainly no guidance about using 
Authentication-Results for end-user consumption.  There is even less basis for 
asserting that it will provide end-user benefit.


Again, the likelyhood of benefits are signficantly is lower than costs.

So DKIM is at a state where there is no offering of filtering advice beyond
the theoretical discussion in RFC5863. The current mailing list approach:

    MLM behaviors are well-established and standards compliant.  Thus,
    the best approach is to provide these best practices to all parties
    involved, imposing the minimum requirements possible to MLMs
    themselves.

is rather defeatist and limits the encouragement for DKIM-Friendly lists.

First, you seem to be placing quite a lot of emphasis on mailing list issues. 
While that's a topic worthy of pursuit -- which is why the working group is 
doing it -- it has not been demonstrated to be a fundamental aspect of DKIM 
success and there is pretty good indication that it isn't.  Of all DKIM-signed 
mail, a relatively small percentage goes through mailing lists.


So for DKIM, filtering is painful as it requires end user specific knowledge
of what lists they subscribed to.

No it doesn't.  This is simply inaccurate and appears to be predicated on a 
logic sequence that is convoluted or not yet validated.  (Choose your poison.)


This is hard enough at small end user
organisation let alone an ISP. The end user is left with an AR header field,
invisibly hidden by the MUA, to try to filtering out forged mail.

DKIM has essentially nothing to do with the task of identifying forged mail, 
nevermind the impossible task of having the end-user doing it.


For reputation service providers the assumption that mail serivce providers
are going to deploy DKIM for the benefit of reputation service providers seems
a little hopeful considering their costs.

And yet it is being deployed.  Nicely.  This suggests rather clearly that your 
conclusion is wrong.


 Don't misunderstand me, domain
reputation has a role in spam reduction and DKIM contributes to this, there
just needs to be more benefit to the sender/receiver without it.

At the end of the day the future I currently see for DKIM is the same as SPF.

Then you do not understand the superiority of DKIM in

    a) labeling to distinguish organizations and fine-grained mail streams

    b) stability of labeling

    c) ability of the signature to survive MTA relaying and alias-type 
forwarding


Some will deploy it but at the end of the day there will be no-one filtering
on its results because of its deficiencies (MLM).

You think that having an author-related signature survive mailing list 
re-posting is critical to the acceptance of DKIM???  I hope you have some 
industry-derived research data to support that assertion, because there's no 
indication that you are correct.


The progress of deployment
will stagnate in the same way as spf because there is no filtering:
(compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and
http://spf-all.com)

After watching folks make these kinds of predictions for a few decades, my 
observation is that the most reliable prediction about them is that they are 
wrong.  Folks making predictions usually have far too little information or 
insight for making serious predictions.

Your prediction falls into that category, especially since it is based on such 
a 
problematic assessment of what DKIM does and how it is intended to be used.


d/
-- 

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

<Prev in Thread] Current Thread [Next in Thread>