DKIM Deployment

[Dave CROCKER <>]

On 1/14/2010 8:04 AM, Jesse Thompson wrote:
> On 1/13/2010 5:47 PM, Dave CROCKER wrote:
> > Depends on the kind of "forwarding".
...
> Right. I'm specifically talking about relaying.

As I recall from earlier discussions with Ned, I believe he is not sanguine 
about DKIM signatures being preserved even in relaying.  I, too, was unhappy to 
hear that assessment from him.  But we did not haggle the details and I remain 
optimistic.

That said, DKIM really is intended for use between infrastructure engines, not 
MUAs.  It /should/ work between MUAs, IMO, but that wasn't an explicit goal. 
That is, it's design is valid for MUA use, but operational deployment into MUAs 
is a secondary concern for DKIM success (or not a concern at all formally, 
although I personally want it to work...)


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

It does. ("relaxed" canonicalization)


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

Exactly.  This is a persistent problem in industry discussions of DKIM use.  IMO 
the fact that it uses cryptography is distracting, even though it is essential.

That's why I keep pressing for summary characterizations to have a different 
focus.

So, RFC 4871 says:

     "DomainKeys Identified Mail (DKIM) defines a domain-level authentication 
framework for email using public-key cryptography and key server technology to 
permit verification of the source and contents of messages by either Mail 
Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this 
framework is to permit a signing domain to assert responsibility for a message..."

Whereas the new Deployment draft (soon to be published)

   <http://tools.ietf.org/html/draft-ietf-dkim-deployment-10>

instead says:

     "DomainKeys Identified Mail (DKIM) allows an organization to claim
   responsibility for transmitting a message, in a way that can be
   validated by a recipient.  The organization can be the author's, the
   originating sending site, an intermediary, or one of their agents.  A
   message can contain multiple signatures, from the same or different
   organizations involved with the message.  DKIM defines a domain-level
   digital signature authentication framework for email, using public
   key cryptography, using the domain name service as its key server
   technology"

Same information, but significantly different focus, IMO.



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

In SPF the limitation is inherent.  For DKIM, it depends upon the relays' 
configuration. Hence, efforts to ensure it works stand some chance of succeeding.


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

He doesn't think it's /practical/.  Somewhat different claim.


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

Yeah, I need to resolve this with him and lock it down.  Sigh.


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

There's a chance we didn't make Relaxed canonicalize things enough.  Massaging 
the internal data of common, structured header field content might well be an an 
example of this.


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

Well, I still believe it's substantial.

But I've come to believe the largest benefit of DKIM is the ability to 
distinguish among mail streams from the same organization.  The fact that the d= 
parameter is independent of From:, Sender:, MailFrom, etc., means that and 
organization can label and build a reputation for different types of mail is 
handles.  SPF is not designed for that flexibility.


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

I haven't heard enough operational data that it can't to be convinced it 
can't.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net