On Jan 10, 2007, at 7:33 AM, Dave Crocker wrote:
Wietse Venema wrote:
>> Perhaps some people are confusing verification and presentation.
>>
I really don't understand all of this hand wringing about True
Verification vs. Mutant Verification Intent on Taking Over Earth.
The protocol document needs to be precise about what it takes for
a properly written verifier to verify a properly signed message.
That's it. Trying to make normative any or all of the ways _not_
to verify a signature is not only a waste of time, it's a hopeless
task.
Mostly +1.
In line with Wietse, we need to distinguish between two, basic
activities. One is verification. I would call the other
"interpretation", rather than "presentation" because it is a
function of the filtering agent -- and can result in a variety of
handling outcomes -- rather than just presentation to the user.
The fundamental point is that dkim-base defines how to create a
signature and how to validate a signature. Anything done after the
basic, interoperable, yes/no validation is outside the scope of -base.
Calling it "policy" is a good way of distinguishing it from the
scope of -base which is intended to be purely mechanism.
The base draft requires the From header be signed. This header might
become modified for EAI compliance. One mode of verification might
therefore always include header copies to allow DKIM verification to
remain robust. It may be better to anticipate that From header may
_not_ play a significant role in the validation/anti-spoofing
process. Instead, perhaps an EAI style identity might be placed
within the DKIM signature. Validation could then include a means to
confirm associations between domains when they differ from what is
found within a specific header. In addition, the originating header
is not always going to be the From header, where EAI fix-ups will
require added heuristics without tangible benefit.
The alternative associative approach also eliminates a need to share
private keys in some fashion. While DNS zone delegation or CNAME
arrangements at specific key leafs might be seen as a workable
solution, either of these schemes require detailed coordination
between at least two parties. This level of coordination will
needlessly increase costs associated with DKIM, and thus make DKIM
less practical in many situations.
An associative scheme with the sending entity would allow these
sending entities to better protect reputations of outbound servers.
It would also permit the email-address domains owners an autonomous
means to opportunistically take advantage of DKIM signing. When a
provider signs within sub-domains unique for each organization
serviced, then such a scheme would also assure that associations
would not open the door for spoofing. This approach avoids private
key sharing, DNS delegation, and the use of CNAMEs that is unlikely
to prove practical. An associative scheme would incur the same
overhead as that of a CNAME as well, and more easily accommodate use
of other headers reflecting the entity introducing the message.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
