[ietf-dkim] Results of survey on DKIM Reputation string use

[Douglas Otis]

On Oct 7, 2007, at 1:39 PM, Dave Crocker wrote:

> Folks,
>
> Last August, Dave Crocker wrote:
>> I've had a brief exchange, with a few folks recently, that  
>> suggests quite a bit of ambiguity about the DKIM-related  
>> information to be used for assessing reputation/accreditation.
>>      Simply put:
>>         When you validate a DKIM signature, what information do you
>>         (intend to) use for querying your reputation/accreditation
>>         data bases?
>
>
> The survey produced a useful set of responses.  I think they  
> suggest a clear
> consensus for using the d= string, as the basis for any public  
> reputation
> analysis.
>
> (What a receiver chooses to do in the privacy of their own  
> filtering analysis
> engine is, of course, their own business.  The question, here, is  
> about a
> common semantic among signers and validators.)
>
>
> Detailed Results:
>
>   d=:  9
>
>   i=:  2
>
>   i=, but d= if no i= present:  2
>
>   s= + d=:  1 (for company-internal signing and use only)
>
> There were some elaborations, with a few folks discussing deeper  
> analyses,
> such as using s=, i= and/or h= for "associative" analysis. I think  
> this draws
> exactly the right distinction between a basic, public semantic  
> standard,
> versus whatever heuristics are added to it privately.
>
> Some comments that were offered struck me as particularly helpful for
> capturing basic issues:
>
>> The d= domain.  It's the only domain that's actually verified.
>
> and
>
>> The name of the signing key is inherently more credible than
>> information that is "protected" by the signing key, including
>> rfc822.from.
>
> and
>
>> The addition of the selector seems particularly useful for segmenting
>> mail along functional lines (person-to-person, marketing,  
>> transactional,
>
>
> Discussion:
>
> With the survey results as background, I'll suggest the following:
>
> Generic DKIM statement:
>
>      When a DKIM signature is validated, the meaning is that a  
> particular
> domain name's owner is declaring some responsibility for the  
> message.  (This
> is offered as
>
>
> So,
>
> 1. That domain name to be used for reputation analysis is contained  
> in the d=
> parameter of the DKIM-Signature header field. It is the parameter  
> intended to
> state the name of the (domain) responsible party.

This assertion will also need to deal with  situations where there  
are multiple signatures.  A signature within an email-address domain  
contained by a header that might have originated the message is  
likely to be given priority.

> 2. The s= parameter MUST NOT be used for primary reputation  
> analysis.  It is
> explicitly NOT intended for use in responsibility (reputation)  
> analysis.  That
> parameter is *only* intended for administrative key management use,  
> such as
> periodically rolling over to a new key.   An organization can have  
> many
> different schemes for the way it performs key management.  A DKIM  
> receiver
> cannot know what scheme(s) are being used. Any use of s= for  
> reputation
> analysis will defeat the ability to use it for strictly  
> administrative purposes.

Okay.

> 3. i= derives from d=.  The derivation means that there is a layer of
> indirection to its meaning and, possibly, some potential for less- 
> strict,
> stable or less valid use.  While possibly useful for secondary,  
> elaborated
> analyses, it MUST NOT be used as the primary string for public  
> standards-based
> reputation analysis.


The i= might not related to any email-address identity within the  
message.  Take for example your suggestion to use sub-domains to sign  
messages when making different assertions.  In this case, the i= of  
the message would be invalid for any of the originating email  
headers.  It might be more interesting to discuss the implications  
when there are implied sub-domain authorizations of email-addresses.

-Doug