----- Original Message -----
From: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
- Quickly disseminate the bad from the good,
Again, how? And I don't think you meant disseminate, but discriminate.
Actually no, disseminate, as in "Query Dissemination" methods, which in
terms for this context; to zoom in on an answer or decision efficiently by
using information available to help separate or eliminate your less probable
choices. i.e. Eliminating the obvious first. What is optimal in query
dissemination is to do this with little overhead.
For DKIM, factors such as:
- Expiration,
- Broken Signing Policies,
- Syntax errors
- Other inconsistencies, and
- other ideas we want to add to help the process.
are all useful for disseminating and as such, it inherently give you a high
payoff and efficiency. Although we might label them as "bad," this has
nothing to do with reputation. It more about following the rules.
Does a message suddenly become "bad" because the signature expired?
I don't think I implied that, in fact, I believe my proposal to use the
message reception time eliminates this idea.
By the way, I am curious. I am wondering why is there is a resistance to a
expiration concept? Isn't expiration an inherent attribute in security and
in a crypto key concept?
Are you now a bad driver because you driver license has expired? Maybe you
are not a bad driver, but you are an illegal driver in the eyes of the
state. Maybe considered even a "bad person" because you not playing by
society protocols. :-)
Anyway, I was hoping DKIM can be used as a deterministic protocol, and if
someone thinks an expiration" concept applies in the area of Key Creations,
Managment and Usage, I think I will have a hard time arguing against it.
But if you administrator guys think its more of a pain than useful, well,
maybe it should be nixed.
From an verifier standpoint, if the concept is part of the protocol, then
you follow it and honor it and don't question why the signer had this
practice. There could be many reasons why the signer has this practice.
- Protect customers/users,
From what?
Malicious mail or harm to the system? .
- Help protect DKIM domains as a standard consistent protocol.
I'm sorry, I don't understand this either.
I hope I don't badly paraphrase Mr. Crocker, but essentially the mantra is:
DKIM is a protocol that assigns responsibility for
a domain and hence their reputation is at stake.
Yet, the only thing DKIM-BASE wants the verifer to do is:
- Find One GOOD signature
even if among a sea of bad signatures. It essentially ignores all
inconsistencies, all failure and all information that will allow a system
incorporating DKIM, among other things, to help a domain keep its
responsibility and reputation in line.
I'd be happy with this logic if you could give me a single legitimate
purpose for this. Thus far I haven't heard any.
I listed three in:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003125.html
I think can come up with a few more useful ideas if needed.
What is unique about Expiration is that it is probably the only
clear item in the DKIM protocol that helps with failure detection:
expiration ----> clear definition for invalid,
no verification required.
But what does this mean? If I am an administrator how would I use this
to provide either myself or the recipient with some value?
I was referring to how there is a mixed philosophy where you have:
Verification is performed:
result = valid >>>> Accept
result = invalid >>>> Ignore as it never happen
No Verification Required:
Expiration >>>>>> Reject
Even though this would be an efficient dessemination, the idea is incorrect
with the signature checking results. This is why in the proposal I
presented, I added the factor of checking for a lid signature before
checking for expiration. This actually makes it less strict then the
current proposal and more inline with the rest of the specs.
Please show me a real use case.
Well, it can't be real because it doesn't exist :-)
But given the option, I definitely see how it can be applied. I gave 3 in
the above link.
Lets see another:
o High Value vs Low Value Email.
Bank believes in DKIM. It signs all mail and sends various promotions
including billing info to email account/customers.
Sends two messages using same selector
a) Promotional (AKA spam), adds 6 day expiration.
b) Billing info, adds 2 day expiration
Now keep in mind this expiration is delivery time limit. It will be
worthless for the verifier to accept these signed messages if they havn't
been received withn the indicated time frame.
o Security Consultant hired to write new security procedures for IT.
He recommands all mail to be signed and that all signed messages have 2 week
expirations for delivery.
Note: I guess at the numbers, but I can see where for important email you
don't want this to be floating around the transport system long as it might
indicate there is a delivery trouble somewhere.
Anyway, I think its useful. I don't see it harming anything and it can add
value. I vote to keep it. If there is more harm, then lets ditch it.
But I also agree with Mark that it can be sidelined and allowed to be
introduced as a helper protocol, like the one I'm writing called DSAP (DKIM
Signature Authorization Protocol). I don't see expiration as important as I
do with signing authorization in general.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html