Re: DKIM Signatures now being applied to IETF Email

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nathaniel Borenstein wrote:
I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM.

Note: We have an advanced implementation of DKIM as a product line so my concerns are not outsider views. My input is 100% based on implementation and field experiences.

Policy was very fundamental to the understanding of DKIM, it was part of the original DomainKeys and DKIM expanded this powerful concept with a wider range of Author Domain policies.

I never disputed the out of scope 3rd party trust policy model but it addressed a different problem - trust, if any, of a valid signature after the violations are filtered by author domain policies, if any. Two different layers and this was outlined in my 2006 DKIM Signer Authorization Protocol (DSAP) I-D.

The problem was a conflict in different market ideas - an unrestricted resigner DKIM mail market which 1st party security controls would conflict with. They simply did not want the 1st party to override any 3rd party signers. This conflict was highlighted in the SSP requirements with the last minute addition in RFC5016:

       "Requirements for a DKIM Signing Practices Protocol"

when item #10 was added in section 5.3 to appease the opponents of 1st party SSP polices:

   10. SSP MUST NOT provide a mechanism that impugns the existence of
       non-first party signatures in a message.  A corollary of this
       requirement is that the protocol MUST NOT link practices of first
       party signers with the practices of third party signers.

         INFORMATIVE NOTE: the main thrust of this requirement is that
         practices should only be published for that which the publisher
         has control, and should not meddle in what is ultimately the
         local policy of the receiver.

         Refs: Deployment Consideration, Section 4.3.

This was unfortunate. On the one hand it suggest we should not meddle in how local receivers will behave yet it imposes a MUST NOT mandate in allowing the 1st party policy to override a 3rd party signature trust policy.

DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message.

It does more than that. DKIM has a fundamental requirement to hash bound the 5322.From field to the signature. Its the only header that MUST be signed. All others are optional. This 5322.FROM bind provide the only anchor possible that can be repudiated.

So there are two principal domains associated with a signature:

   Signer        d= value in signature
   5322.From     DKIM requirement

By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since.

I don't see this. The resigner can be totally opaque with no association with the original domain. The signer::author association begins with the original signature creation by the author domain selecting a signer and/or prearranged with an outsource signing service.

Now, what people are looking for as well, is when there is resigner::author association when the author is participating in a resigner network. Currently we call this a 3rd party Authorization.

With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit.

Heuristic wrappers are interesting but its a different problem. It doesn't adequately address what a deterministic solution can do for you.

If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test.

There you go, you made an POLICY STATEMENT - translate it into a protocol for everyone to follow and check.

That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder.

This is all besides the point. Its all about detection what YOU think is a violation of a protocol logic. Whatever you produce in REPUTE, you are producing a idea for people to follow consistency based on some baseline rules established.

We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed.

There are plenty of authentication protocols that works very well, and fundamental to our current network.

The issue here is a DKIM signer market run wild uncontrolled and if we don't get our act together soon to put a security wrapper around it, it risk becoming yet another wasted header with little to no value and perhaps limited to exclusive communications in private communications networks.

I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with. The best is the enemy of the good. -- Nathaniel

I have invested dearly in dollars, time and energy and we have produced an advanced DKIM implementation into our product line with a high degree of mail component integration - its a commercial product, not just for our own use.

My concerns are 100% sincere as I believe that it might not be too late for DKIM to correct what has occurred - the deemphasis of the single DKIM requirement to hash bind the 5322.FROM author to the signature means.

This is an association you can not ignore because the entire mail infrastructure relies on the 5322.From as a fundamental header across all mail networks, all mail devices, etc, etc. etc. This is a not a question that can be separated which unfortunately the DKIM specification Abstract states as a goal of DKIM:

   DKIM separates the question of the identity of the signer of the
   message from the purported author of the message.

What question is that? Is the question this?

   Do author domains have any say on who signs for them
   and who/what is considered unauthorized signatures
   versus authorized resigning?

Anyway, thanks for your comments.

--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com




_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]