DKIM Deployment

[Dave CROCKER <>]

With luck, my note will be compatible with Jim's...

FWIW, as a meta-comment, I'll note that debating concrete technical details with 
Ned is essentially always a losing effort.  He simply does not get details wrong 
and he usually knows all the relevant details and he's careful in what he says.

I disagree with him often about policies, approaches and goals, but I've learned 
to take him at his word about underlying details.

Now to the matter of /these/ details...


On 1/13/2010 12:19 PM, Jesse Thompson wrote:
> Well, it seems that my understanding of DKIM was way off.  I had always
> assumed that DKIM was immune to the issues involved with forwarding. I

Depends on the kind of "forwarding".  That's why the Internet Mail Architecture 
document distinguishes among some significantly different types of actions that 
move a message through a node, notably relaying, versus mediation. (See RFC 
5598, especially Section 5)

Imagine forwarding through a mailing list exploder, where the exploder only 
sends a daily digest, combining multiple messages.  Would you expect their DKIM 
signatures still to be valid.  (I certainly hope not.)

When a forwarder does major changes to the bits of a message, then a mechanism 
based on the original bits can't possibly be expected to still work.  DKIM does 
hashes on some of those original bits.  So the survival of a DKIM signature 
depends having those bits stay unchanged.  (DKIM has some ability to survive 
specific types of changes, but consider them very, very mild.)


> had hoped to use DKIM as a way to whitelist mail from specific
> organizations (and to not depend the messages coming to our servers from
> specific sources.) Now, I don't see how DKIM is significantly better
> than SPF, or just plain old IP exemptions. :-(

You probably want to treat DKIM as authenticating authorship and want to 
whitelist the author.  That's not what DKIM is designed to do, so it's not 
surprising it fails to satisfy that goal.

DKIM is intended to provide a valid identifier from origination to the 
associated delivery, across multiple MTA relaying hops. SPF can't do that.

DKIM signatures /might/ survive a re-posting and re-delivery, depending upon how 
much damage is done between the intermediary's delivery and subsequent re-posting.


> > I guess I was misled by statements such as:
>
> > "   If the only modifications en-route involve the addition or
> >      modification of header fields, the signature should remain valid;
>
> This is total bunk. DKIM signatures typically cover the content of any header
> field the signer chooses, and often cover various headers that end up getting
> modified in transit.

That's the choice of the signer.  The fields typically signed do not get changed 
by MTAs.  Some, such as Subject:, often get changed by Mailing Lists, but those 
are user agents and they can and do do massive damage to the bits.  A signer 
could reasonably choose a different set of header fields that are less likely to 
be modified.


> >      also the mechanism includes features that allow certain limited
> >      modifications to be made to headers and the message body without
> >      invalidating the signature.
>
> Features which are used more often than not.

The goal of trying to survive mailing list handling is a controversial aspect of 
DKIM's design.  There's a significant contingent who believe it is not helpful 
enough to warrant the extra mechanism.  But, then, it's a pretty inexpensive 
mechanism.

Your reaction probably points out that some of the problem with a limited 
survival mechanism like DKIM has is that it is too easy for people to place the 
wrong expectations on it for survival.


> >      Some suggest that this limitation could be addressed by combining
> >      DKIM with SPF, because SPF (which breaks when messages are
> >      forwarded) is immune to modifications of the e-mail data,
>
> >      http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
>
> I have to say that this is also pretty silly. Forwarding is a major problem

Yeah, but it's true that lots of folk like to claim a complementary potential 
between SPF and DKIM.  A followup question of "how?" essentially never gets a 
substantive response.


> with both DKIM and SPF; albeit for different reasons. You can solve SPF
> forwarding issues by using SRS - which actually isn't that hard to do. The 
> only

SRS changes the semantics of message.  That's rather more damage than anyone 
ought to try to justify.

And the fact that is easy to implement at an individual site means little about 
its systemic impact or the (lack of) incentive to gain system-wide adoption.


> reliable way to make DKIM work across all the stuff intermediaries do
> (forwarding, iist expansion, MIME downgrading/upgradinng, content conversions,
> the list of possibilities goes on and on and on) is to resign. But the new
> signature will be done by a different authority who probably has a different
> associated reputation.

Wrong goal.  What you really want is for the Mailing List to do signing so that 
you can assess the reputation of that operator, rather than of each of its 
subscribers.


> Mind you, I'm not saying DKIM is useless. It solves a certain class of problem
> fairly well: Validation of emails sent from one administrative domain to
> another. The issue lies in trying to use it outside it's realm of
> applicability.

Well, yeah, that issue a challenge for any system...


> > I [mis]interpret that to mean that DKIM should be used in a way that
> > supports forwarding, which led me to believe that the signatures could
> > be verified at any hop.

Relaying, not forwarding.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net