Eric (and Mark),
First, let me say thanks for taking the time to reply.
I've bounced around this all evening and decided it isn't worth the time to
rock this (leaky) boat anymore.
But I will say this for the record:
Whether you know it or not, you are making indirect technical and indirect
local policy decisions with the assertion:
"bad signatures --> treat as if no signature was even present"
So just because you don't want to say anymore about Local Policies or how
invalid DKIM signatures are possible, saying it should be treated as if as
NO SIGNATURE is present, it is making a technical and local policy decision.
I think it is a failed and flawed design concept and I have not been
convinced that it is not.
I can only advise you of this:
If mailing list or middle ware tampering is your problem, then I advise you
to quickly resolve this because there is no doubt in my mind the
exploitation of using invalid DKIM signatures is going to be give DKIM a
black eye and become a major thorn on the side. To believe only "GOOD
Signatures" is the only form of good messages and BAD signatures as no
signature is unrealistic.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Eric Allman" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: "IETF DKIM WG" <[email protected]>
Sent: Wednesday, February 15, 2006 9:21 PM
Subject: Re: [ietf-dkim] testing Message Corpus & question for base spec
>
>
> --On February 15, 2006 6:36:40 PM -0500 Hector Santos
> <[EMAIL PROTECTED]> 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
>
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
