[ietf-dkim] mutant message validation, was Base issue: multiplelinked signatures

[Douglas Otis]

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