[Top] [All Lists]

Re: [ietf-dkim] The problem with the DKIM design community

2013-06-25 15:26:57

On Jun 22, 2013, at 9:49 PM, Michael Deutschmann 
<michael(_at_)talamasca(_dot_)ocis(_dot_)net> wrote:

Ukh.  This again.

I think I see what the problem is with the DKIM design community.

Most of you assume that once DKIM and an accessory protocol of choice
(DMARC, etc.) reaches a sufficient amount of respect from the RFC
machinery, it will magically be deployed absolutely everywhere it is

Otis is just a shade more humble.  He thinks the magical deployment will
occur, but will be accomplished by a jerk literal genie, who will try to
pass as much bad mail as possible while keeping to the letter of the
final DKIM spec.

Dear Michael,

A serious security vulnerability occurs when system administrators logically 
follow DKIM deployment instructions.  They likely have a reasonable desire to 
avoid complains caused by reactive Bayesian filters.  This filtering is 
supplanted by more deterministic message acceptance based on trust established 
by a DKIM signing domain specifically as suggested by the deployment 

Rather than DKIM admitting a process error where valid signatures are returned 
for messages having invalidly prefixed header fields, the fix was to suggest 
there is some undefined check left to some undefined subsequent agent.  So much 
for providing clean protocol layering.   Use of DKIM requires an undefined 
"degrading" process per section 8.15 to be implemented subsequent to signature 

This is putting the cart before the horse since a DKIM validation process must 
walk up and down the entire header field stack.  It is also clear very few 
domains implement the non-intuitive double listing of singleton header fields.  
Even so called "high value" domains don't bother with this ugly hack.  The 
OpenDKIM implementation can place the cart behind the horse, but as a seldom 
used option.  An option that should be a REQUIREMENT. 
5.4.  Inbound Mail Filtering
  DKIM is frequently employed in a mail filtering strategy to avoid
   performing content analysis on email originating from trusted
   sources.  Messages that carry a valid DKIM signature from a trusted
   source can be whitelisted, avoiding the need to perform computation
   and hence energy-intensive content analysis to determine the
   disposition of the message.

   Mail sources can be determined to be trusted by means of previously
   observed behavior and/or reference to external reputation or
   accreditation services.  The precise means by which this is
   accomplished is outside the scope of DKIM.
8.4.  Email Infrastructure Agents
Inbound:   When an organization deploys DKIM, it needs to make
         sure that its email infrastructure components that do not have
         primary roles in DKIM handling do not modify message in ways
         that prevent subsequent verification.

         An inbound MTA or an MDA can incorporate an indication of the
         verification results into the message, such as using an
         Authentication-Results header field [RFC5451].
8.5.  Mail User Agent
Inbound: An MUA can rely on a report of a DKIM signature
         verification that took place at some point in the inbound MTA/
         MDA path (e.g., an Authentication-Results header field), or an
         MUA can perform DKIM signature verification directly.  A
         verifying MUA needs to allow for the case where mail has been
         modified in the inbound MTA path; if a signature fails, the
         message is to be treated the same as a message that does not
         have a signature.

3.8.  Input Requirements

   Accordingly, DKIM's design is predicated on valid input.  Therefore,
   Signers and Verifiers SHOULD take reasonable steps to ensure that the
   messages they are processing are valid according to [RFC5322],
   [RFC2045], and any other relevant message format standards.
  See Section 8.15 for additional discussion.

Douglas Otis

NOTE WELL: This list operates according to
<Prev in Thread] Current Thread [Next in Thread>