[ietf-dkim] Keys vs. Reputation

[Douglas Otis]

On Aug 21, 2006, at 5:19 PM, Dave Crocker wrote:

>
>>> It seems too early to know how key selectors might be used,
>
> No it doesn't.
>
> A selector adds one level of name granularity.  So does a regular  
> sub-domain name.
>
> If the purpose of an extra level of granularity is semantic, then  
> it belongs in the actual name.  That is, it belongs in the d= string.

There are likely practical considerations that will affect the  
general application of this rule.

Big-Bank.com has a few thousand email-addresses assigned to employees  
and specialized services all under their parent domain of:

  local-part at Big-Bank.com

Now Big-Bank.com is told this must change to conform to a "semantic"  
requirement of someone's reputation system using the d= parameter  
within the DKIM signature header.  : (

A major advantage offered by DKIM was-

DKIM Base:
,---
|o the message signature is written as a message header field so that
|  neither human recipients nor existing MUA (Mail User Agent)
|  software are confused by signature-related content appearing in
|  the message body,
'___

The added security afforded by DKIM was absolutely transparent.  That  
goal must now be abandoned to support a semantic for a reputation  
service that changes the email-addresses being used?

When Big-Bank.com is coerced into using subdomains to partition their  
messages, their customers will see more complex domain names within  
the email-addresses and might become confused by what they see.

Perhaps this might be subdomains like:

  local-part at Employees.Big-Bank.com
  local-part at Services.Big-Bank.com
  local-part at New-Accounts.Big-Bank.com
  local-part at Promotion.Big-Bank.com
  local-part at Western-Region.Ads.Big-Bank.com
  etc.

A profusion of subdomains along with the extra text now must be  
carefully examined.  This added profusion will likely make Big- 
Bank.com an easier phishing target.  Will Big-Bank.com's customers  
know the difference between a '.' and some other character used in a  
domain name?  Things like the following may go unnoticed.  Poor grandma.

  local-part at New-Accounts-Big-Bank.com
    instead of
  local-part at Big-Bank.com

> The construct of selector is for a different purpose.  It is an  
> administrative construct, not a semantic one.

True.  The key selector is allowed to use multiple labels.  One of  
these labels could be dedicated to the purpose of segregating the  
domain without affecting the critical appearance of their email- 
address, or requiring everyone to understand that-

Tom.Jones at Big-Bank.com
  is now really the same person at
Tom.Jones at New-Accounts.Big-Bank.com

When people already recognize an email-address, changing the email- 
address will not improve a recipient's trust with respect to who is  
now sending them messages.


>>>   Selectors might be used to partition the domain's messages.
>
> It has been a while since I have quoted my favorite system's  
> engineer.  His expertise in considering trade-offs has often been  
> undervalued, so I tend to make a point of crediting him in these  
> circumstances:
>
>      "We could do it, but it would be wrong."
>                    -- R. Nixon; WG Tapes.

     “You see things; and you say, 'Why?'
      But I dream things that never were; and I say, 'Why not?'
                      -- George Bernard Shaw

> If you want to partition among messages -- and by this, I assume  
> that what was actually meant was to label messages in logically  
> different bins, for the purpose of permitting differential  
> assessments (reputations) -- then that is what sub-domains are for,  
> in the d= parameter.

   The d= parameter remains unseen in the DKIM header, which is good.

   For the sake of a reputation assessment, this changes the  
appearance of the address, which is not good.

> Let me stress a basic point:
>
>      The instant that a selector is used semantically, it becomes
>      worthless for its primary purpose, namely support of multiple
>      keys for the same d= domain name.

This basic point is very wrong.  The s= parameter already supports  
multiple labels.  Only _one_ label is needed to enable multiple keys  
for the same d= domain.  For example:

   d=example.com

   s=summer._safe
   summer._safe._domainkey.example.com key

   s=winter._safe
   winter._safe._domainkey.example.com key

   s=fall._promo
   fall._promo._domainkey.example.com key

   s=spring._employee
   spring._employee._domainkey.example.com key


These are examples where the email-address is allowed to remain  
unchanged, multiple keys are provided for the same domain, and yet  
separate reputation assessments remain possible.  Here are examples  
of three categories of messages _safe, _promo, and _employee.  The  
base domain is likely well recognized as their trademark.  Flooding  
this domain name with subdomains reduces the clarity of the email- 
address.


>> Not all users within a domain are equally trustworthy.
>
> Quite true.  And if the signer wants to distinguish among "users"  
> by having different signatures, then use different d= sub-domains.

Which subdomain or domain is more trustworthy?  Your scheme demands  
email-addresses be modified to comply with a reputation scheme.  Why  
not have the reputation scheme achieve the same goal as that of DKIM  
and remain transparent?  DKIM will require annotation to convey the  
signature results, reputation can be included within this  
annotation.  The address does not need to change.


>>> This trust may be partitioned by using the 2822.From local-part,  
>>> different selectors, or perhaps an r= parameter.
>
> No.

If DKIM does not offer a means to assure the validity of the  
2822.From address, then DKIM will have missed an important goal.   
Knowing who you are communicating with is an extremely important  
aspect of trust.  This trust is not improved by changing the email- 
addresses being used.

-Doug