Subject: [ietf-dkim] no signature or bad signature

From: "J D Falk" <[email-masked]>
Date: Mon, 24 Dec 2007 12:39:03 -0500

[Sounds like this message never got to the list, but it's in the
archives at http://mipassoc.org/pipermail/ietf-dkim/2007q4/008784.html ]

Wietse asked:

> Is no signature equivalent to a bad signature?

For the pure authentication verification use case, where anything not
authenticated is inauthentic, there's no difference.

When debugging a DKIM installation on behalf of the signer (why some
messages don't verify when I thought they would, etc), I'd very much
want to know whether there was no signature or a bad/unverifiable
signature.

When calculating reputation on behalf of the verifier (which is out of
scope and will never be standardized, but is still a known valid use
case), I'd be inclined to record them as separate values...and then look
at additional data to determine whether it was more likely to be
accidental or malicious.

> Will you give "no signature" equal treatment to "bad signature", or
> will you give mail with bad signatures (such as a valid header that
> was pasted on top of a forged body) more favorable treatment?

If we're talking about the pure authentication case, they'd get the same
treatment.  If we're talking about the debugging case, the verifier may
treat them the same way but the signer would want to know the difference
(as reflected in Murray's DKIM reporting draft.)  If we're talking about
the reputation case, the final treatment would depend on external
variables & calculation.

I recognize that these three are not the only use cases, but I think
they show a sufficient range.

--
J.D. Falk
Receiver Products
Return Path 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Dec 2007 11:51:24 -0800

On Dec 24, 2007, at 9:39 AM, J D Falk wrote:

> If we're talking about the pure authentication case, they'd get the  
> same treatment.  If we're talking about the debugging case, the  
> verifier may treat them the same way but the signer would want to  
> know the difference (as reflected in Murray's DKIM reporting  
> draft.)  If we're talking about the reputation case, the final  
> treatment would depend on external variables & calculation.

Sources, such as mailing-lists who reformat message content, change  
subject lines, and append ads or unsubscribe information, are likely  
emitting a significant number of corrupt DKIM signatures, perhaps even  
several corrupted signatures per message.  Verifiers wanting to avoid  
their resources being wasted by corrupt DKIM signature validation,  
might create a client list of known corrupting sources to exclude DKIM  
verifications.

To conserve resources, verifiers might first check SSP records and  
perform DKIM signature validations only when required for acceptance.   
Messages with valid DKIM signatures will likely be for a small overall  
percentage, so checking policy first for each message, regardless  
whether a DKIM signature is present, is not likely to increase the SSP  
associated overhead, and can significantly reduce the DKIM associated  
overhead.  Client lists to exclude DKIM verifications might also be  
used to grant policy exceptions as well.  It will be difficult to know  
how DKIM will be handled when faced with abuse.  It is somewhat naive  
to say it is not happening now, so the DKIM WG should not consider the  
implications of abuse/DoS mitigating strategies.

Retaining a modicum of security requires a means to inform recipients  
of the DKIM message state.  Partial signature coverage represents a  
fairly problematic and likely error prone DKIM state to convey.   
Methods to convey boundary conditions of partial signatures has not  
been standardized, and might be trivial to defeat.  The DKIM WG should  
limit policy compliance recommendations to the use of full signature  
coverage for all messages when either "all" or "strict" policies are  
published.  DKIM should identifying which domain initiated the  
message, and not just some of the message.

-Doug