[ietf-dkim] Keys vs. Reputation

[Douglas Otis]

On Aug 21, 2006, at 2:15 PM, Dave Crocker wrote:

> Folks,
>
> Wietse Venema wrote:
>> With a shared signing key+domain, if one of those thousands of  
>> domains mis-behaves, all the other domains could suffer from the  
>> bad reputation of that shared signing key+domain.
>>
>> Thus it's better to avoid shared signing key+domain scenarios.
>
> Based on some conversations today, I think we need to do a better  
> job of distinguishing keys from reputations (identities).
>
> It is even more important that we carefully distinguish between  
> internal operational policies, versus the information that a signer  
> must make public. Good protocol design makes it imperative that we  
> separate these and that we make the portion visible to -- or,  
> rather, imposed upon -- other protocol participants be absolutely  
> as small as possible.
>
> (I am using the term "reputation" as a placehold for the wide range  
> of analyses that can be performed, once one believes that a claimed  
> identity is valid.)


In addition to the signing domain and key selector, DKIM can signal  
the validity of the 2822.From address.  These are separate identities  
that can be assessed and used to accrue a behavioral history.  The  
assertion of 2822.From validity can be done via i= syntax or by way  
of a policy assertion of a signing domain outside the 2822.From domain.

DKIM does not prevent replay, but might be effective at indicating  
when the source of an identity appears suspicious.  DKIM does not  
identify who created the message envelope and thus does not identify  
the entity responsible for abusive sending.

Certification of account handling, signing practices, and the  
validation of the 2822.From might be where reputation becomes  
relevant and practical.  This could convey whether the signing domain  
ensures the validity of the 2822.From address, the frequency an  
2822.From address within an outside domain is re-confirmed, how  
accounts are established, how quickly abuse reports are resolved, etc.


> Keys
> ----
>
> The allocation of private keys provides a means of controlling who  
> can create signatures, under a particular domain name.  The  
> selector is used to support multiple simultaneous keys, under that  
> single domain name.  Selectors can be used for something as simple  
> as introducing a new key to replace an old one, or as complex as  
> support of an army of mobile users who do not submit mail through  
> the organization's servers.
>
> The critical point about such a set of keys/selectors is that they  
> all map to a single domain name and that that single domain name is  
> the basis for reputation analysis.

It seems too early to know how key selectors might be used, whether  
reputation accrues to just the parent domain, and the role of the  
2822.From address.  Perhaps a convention is established for  
transactional messages where the right-most label in the key selector  
is named "safe".  Selectors might be used to partition the domain's  
messages.  Not all users within a domain are equally trustworthy.   
This trust may be partitioned by using the 2822.From local-part,   
different selectors, or perhaps an r= parameter.  It seems premature  
to speculate on how reputation is best applied or how the domain's  
traffic is partitioned, identified, and reported.

Per the DKIM charter:
,----
|To prevent this task from becoming unwieldy, several related topics are
|considered out of scope for the DKIM working group. These topics
|include:
|
|* Reputation and accreditation systems. While we expect these to add
|  value to what is defined by the DKIM working group, their development
|  will be separate, and is out of scope for the DKIM working group.
'----


-Doug