DKIM Deployment

[Jesse Thompson <>]

On 1/13/2010 5:47 PM, Dave CROCKER wrote:
> 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.

Oh, yeah.  Ned always wins on the details.  That's why I see this as 
such a blow to the potential usefulness of DKIM.


> 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.)

Right.  I'm specifically talking about relaying.

Although, I do admit that I had assumed (or, hoped) that DKIM would work 
for messages that are forwarded between multiple end-user accounts.

I never quite made the logical jump to mailing list exploders.


> 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.)

Yeah, that makes sense.

My original intent with bringing this up on Info-IMS was to find out why 
SJSMS was making these changes, and how I can configure it to stop 
making the changes.  Needless to say, I was surprised with Ned's response.

But, Ned is correct, of course.  Message-ID and Message-id are both 
valid, and can be interchanged by the relaying MTAs, so DKIM is probably 
incorrect to rely on the assumption that MTAs won't make these changes.

So, if headers are allowed to be changed by relaying MTAs, then 
shouldn't DKIM accommodate for this by normalizing the headers in a very 
strict way prior to signing and prior to verification?


> > 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.

Yes.  My intent was to authenticate the source, as an improvement to 
whitelisting a last hop IP address, but have it work across multiple MTA 
relaying hops and (hopefully) multiple forwarded email accounts.

I see now that I'm trying to apply an S/MIME paradigm to DKIM.


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

Neither can DKIM, according to Ned.


> 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.

The example here is with validating across multiple MTA relaying hops.

Ned is saying that this isn't possible.

"   And the fact that some schemes, like the use of  DKIM across
    multiple transport hops, depend on this myth being true doesn't
    make it any less of a myth.

    This doesn't mean you cannot use things like DKIM. But if you want
    to use them, you have to be willing to apply DKIM signatures at the
    exact moment of egress, evaluate DKIM signatures at the exact
    moment of ingress. Nothing else is going to work.


> > > 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.

Yeah, the signer can shoot themselves in the foot by choosing the poor 
headers.  However, I think that the signer fully expects the Date header 
to be left intact.  Again, strict normalization might be the only 
solution to this problem.


> > > 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.

Yes, I put the wrong expectations on its survival.  But that is because 
I had understood survivability as the primary advantage of DKIM over SPF.


> > 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.

corrected.

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

Jesse

--
  Jesse Thompson
  Division of Information Technology, University of Wisconsin-Madison
  Email/IM:

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature