[ietf-dkim] testing Message Corpus & question for base spec

[Eric Allman]

--On February 15, 2006 6:36:40 PM -0500 Hector Santos 
<hsantos at santronics.com> wrote:

> ...
> Just a suggestion for a new section:
>
>     1.5 Basic Requirements Summary
>
> Then seach for all "requir" or "MUST" in the document, consolidate
> it and try to summary it in this basic section in outline format,
> maybe with each having a reference to the specific more detail
> section as well.

Interesting idea, but I think it's probably best held off until the 
document is essentially done so we don't get things out of sync.

>> ...
>> The problem is turning this into English.
>
> [FLAWED TECHNOLOGY!]
>
>     If one or more signatures are valid, then process the message as
>     a good signature.  This includes if there exist one or more
>     bad signature.  As long as there is 1 good signature, process
>     the message as a good signature.

OK, I made the last paragraph of Section 6 (i.e., right before 6.1) 
read

        Verifiers MUST apply the following steps in the order listed.
        In many cases these steps say that a "DKIM-Signature" header
        field should be ignored, e.g., because it is malformed or
        because the signature verification failed.  In such cases
        verifiers SHOULD proceed to the next signature, and treat the
        message as verified if any signature succeeded, ignoring the
        bad signatures.  The order in which signatures are tried is a
        matter of local policy for the verifier and is not defined
        here.  A verifier MAY treat a message that has one or more
        bad signatures and no good signatures differently from a
        message with no signature at all; again, this is local policy
        and is beyond the scope of this document.

I hope this captures what we are both trying to say.  There is one 
possibly controversial point here: that a verifier MAY treat a 
message with bad signatures differently than those with no 
signatures.  I really view this as out of scope, since that's a local 
policy issue, so perhaps it should be deleted entirely.

> ...
> I would change your pseudo code or implement it as such:
>
>       total_sigs = read_all_signatures();  // v1.1 HLS
>       sort_signatures_into_preferred_order();
>       good_sig = false;
>       something_wrong[] = {nope};   // v1.1 HLS
>       foreach sig in signatures {
>           //-------------------------
>           // v1.1 HLS
>           something_wrong[sig] = malformed || missing key ||
> expired key || ...
>           if (something_wrong[sig])
>               continue;
>           //-------------------------
>           if (good_sig = check_sig_ok(sig))
>               break;   // from foreach
>       }
>
>       // v1.1 HLS
>       not_quite_kosher = false;
>       foreach wrong in something_wrong
>          if (wrong != nope) {
>            not_quite_kosher = true;
>            break;
>          }
>       }
>       //
>
>       if (good_sig)
>           if not_quite_kosher and LocalPolicy_AcceptWrong then //
> v1.1 HLS              reject(something_wrong[]);   // v1.1 HLS
>           else
>              process the message with signature(something_wrong[]);
>       else
>           if (total_sigs and LocalPolicy_AcceptWrong)
>              reject(something_wrong[]);   // v1.1 HLS
>           else
>              process the message as though there were no signature
>
> In short, if there is any attempt to use a new set of DKIM
> information, and its incorrect, then it should it a LOCAL POLICY
> DRIVEN as to how this will handled.  It is not like there is a "no
> signature" because that isn't true. There is a signature, just
> incorrect and this information is vitality important.

I think we're agreeing, although I think your last "if" block has 
some conditions reversed (or I'm getting confused over variable 
names).  It seems to say that I have a good signature but something 
is wrong and my local policy allows this then I should reject the 
message.

My initial draft actually included something like this but I pulled 
it out for simplicity; mine just included a "something failed" 
boolean that got set in the obvious places.

> I can not under good conscious believe there would be such a think
> as a GOOD message when there is something wrong with it.
>
> Grant it, I think your code assumes and attempts to desensitize the
> "List Server" issues. But it doesn't take into account the high
> potential abuse and extreme overhead that will be placed across the
> network on so many systems.  Over 80% of SMTP transactions are not
> SMTP compliant (intentionally).  Is DKIM the exception to this high
> probability?

Dream on, although I'm surprised the number is so high --- perhaps if 
you include spam engines.  But here is where I think we have a 
disagreement; I am concerned, at least in the short run, about 
signatures that get trashed for innocuous reasons, such as mailing 
list exploders.  I don't think such messages should be rejected. 
This is, of course, local policy.

eric