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" <eric+dkim(_at_)sendmail(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
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
<hsantos(_at_)santronics(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html