Analysis of DKIM failure

[Hector Santos]

In the DKIM-OPs mail list, a message and response regarding how to
detect which header failed in a DKIM signature was posted:

http://mipassoc.org/pipermail/dkim-ops/2009-November/000175.html

The following is my assessment of the issues here. Your comments are
welcomed.

This post and response exemplies all the key concerns about DKIM:

- The lack of benefits of tracking mail integrity problems.
- The flawed RFC 4871 "Invalid == No Signature" mandate
- lack of DKIM policy support
- The "Cry Wolf" Syndrome
- lack of wide adoption incentive for DKIM without policy

If the domain did not expect failure, for whatever reason, then DKIM
currently does not allow any protection against unexpected failure.

If the domain begins to sign mail without a policy concept, the domain
puts itself at risk and its receipients at risk by creating three
forms of USER viewable results. If we use a color system:

- GREEN: Message is 100% valid
- YELLOW: Message is not 100% valid (one header is bad)
- RED: Message is not signed at all.

What is more important is if the YELLOW and RED was expected by the
original domain and what the domains wishes to be done by the
receivers before passing the back to end users or forwards the message
to other receivers.

If RFC 4817 Invalid=NoSignature mandate is followed without policy,
as predicted people will begin to analyze what specific failed part
caused the invalid signature and try to highlight this to users.

Now imagine if there was a policy concept (ADSP) wth the RFC 4871
invalid=nosign mandate, the possible color changes here are:

For DKIM=DISCARDABLE

- GREEN: Message is 100% valid
- RED: Message is not 100% valid (one header is bad)
- RED: Message is not signed at all.

For DKIM=ALL, it depends on what RFC 5617 says about 1st vs 3rd party
signing allowance. So a possible color scheme:

- GREEN: 1PS Message is 100% valid
- GREENISH: 3PS Message is 100% valid
- YELLOW 3PS message is not 100% valid (one header is bad)
- REDISH: 1PS Message is not 100% valid (one header is bad)
- RED: Message is not signed at all.

Many people are saying that REPUTATION is needed here to resolve
broken signatures, even the valid ones.

Lets consider reputation for each color:

- RED: Message is not signed at all.

Here, the 1st party domain (5322.From) can be checked against some
DKIM Domain Certification database. The domain reputation policy,
not ADSP policy, might be "Message must be signed" and since there is
no signature, the receiver can mark this RED.

- REDISH: 1PS Message is not 100% valid (one header is bad)

Here it depends on what the domain reputation policy, again not ADSP
policy, might be "Message must have a valid signed by 1st " and since
there is no valid signature, the receiver can mark this RED but if we
want to allow for detection of header failure, then it might be marked
as REDISH. Again, it depends on DOMAIN REPUTATION POLICY.

- YELLOW: 3PS message is not 100% valid (one header is bad)

Here we are looking up the 3rd party signer domain reputation. The
question becomes what is the association with the 3rd party domain
with the 1st party domain? A query might be:

"We have a 1st party domain signed by a 3rd party and one of the
headers XYZ is
broken. Is this acceptable?"

The reputation vendor might say:

"We know the first party domain, and this might be a low mail
integrity issue. Mark Yellow"

If the vendor does not recognize the 1st party domain, then it might
sugges to mark it REDISH.

GREENISH: 3PS Message is 100% valid

Here the 3rd party domain reputation policy migh be:

"We DO NOT know the first party domain so mark it GREENISH"

If the 1st party domain is known to the repuation vendor, then it
might suggest to mark it GREEN.

And so on.

Overall, whether its ADSP put REPUTATION, a DOMAIN policy is still
required to help explain these indeterminant conditions.

The problem with all these is the "Cry Wolf" syndrome. When the user
sees perpetual GREENISH, YELLOW or REDISH results and sees no real
problem, then the value of GREEN or RED diminishes.

Policy is required in all cases, whether its ADSP or REPUTATION. For
example, for DKIM=ALL, it can expanded to say:

- If a 1st party signature failures (no 3d party signature is
present), then this should behave as
DISCARDABLE

- If a 3st party signature fails, then this should behave as
DISCARDABLE

So its more than just saying we need to allow 3rd party, we need to
also say they better do it right if they are going to be allowed to
resign.

Overall, we need three policues:

- 1st party only semantics
- 3rd party only semantics
- Mixed 1st party and 3rd party only semantics

But it really does't matter if 3rd party resigners ignore ther 1st
party policy semantics. We need to protect the 1st party semantics
before 3rd party semantics can be worked out.

--
Hector Santos
http://www.santronics.com