ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] How SSP will assist DKIM-BASE

2007-12-17 12:29:21

On Dec 14, 2007, at 10:51 PM, Hector Santos wrote:

Hector Santos wrote:

Nevertheless, this breakdown should be adjusted to recognize that an invalid signature is equivalent to no signature per the specification.
It did.  Read the message again.

More to the point Doug. The reason I showed it separate was to illustrate there is a high confidence validation (non-repudiation) when there a true no signature state versus the condition where the state is artificially altered from a failed signature to non signature. The later introduces less confidence where the former yields full confidence. When you fold it, you have false positives. In short, it makes the ALL and STRICT policies less reliable. It weakens the policy.

Does that make sense?

Neither an "invalid signature" nor "no signature" offers a safe or any significant difference for non-repudiation. Your assumption appears based upon a invalid signature offering greater confidence in a message source than would no signature. Giving a message with a broken signature credit is a dangerous policy. Nevertheless, this view seems supported by RFC 4781 section 4.2 Interpretation states: "Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified."

Section 4.2 is not clear that this prohibition on signature removal is to be for issuing a "different" message from the one originally signed. In addition, there are cases where a From email-address might legitimately appear in a message which is either not signed, or signed by a different domain. There is a practical aspect in regard to credits and the potential for abuse as well.

When initially structured to give messages with bogus signatures credit, this ensures DKIM will be abused in this manner. Removing invalid signatures avoids being seen as a domain that "intentionally" produces invalid signatures, and being categorized as a domain issuing "bogus" DKIM signatures. Protecting resources needed to validate DKIM signatures will likely need to avoid sources producing "bogus" signatures. If this comes to pass, then Section 4.2 of RFC4781 would be offering fairly poor advice. The mistake of giving credit to invalid signatures ensures why not removing invalid signatures is ultimately bad advice. Giving _any_ credit for an invalid or bogus signature ensures a method for abuse. : (

-Doug


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