Subject: [ietf-dkim] RFC4871bis: considering some guidelines to the effort

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Mar 2009 10:42:39 -0700

Folks,

What is the scope of problems DKIM should try to protect against?

A DKIM signature means that whoever controls the DNS entry for the SDID is 
taking some responsibility for the message.  A random bad actor, out there in 
the wilds of the Internet, cannot use that SDID.

This is the core benefit of DKIM.

Then there is the question of controlling different employees, within the 
organization that owns the SDID.  Perhaps I'm authorized to do signing, but the 
janitor in my organization isn't.

Should a receiver that is validating a signature be asked to take on the burden 
of enforcing access rules within the signing organization?

Protecting against outside attacks is inherent in DKIM's goal.  Protecting 
against attacks or misbehaviors from within the domain owner's own organization 
strikes me as an inappropriate shifting of enforcement burden onto the recipient.

If the working group agrees, then we have an opportunity to simplify DKIM.

Similarly, there are some features that aren't getting used, and that are not 
showing any signs of getting used.  Dropping them also permits making DKIM 
substantially simpler.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Mar 2009 13:57:23 -0700

On Mar 20, 2009, at 10:42 AM, Dave CROCKER wrote:

> A DKIM signature means that whoever controls the DNS entry for the  
> SDID is taking some responsibility for the message.

It is reasonable view a DKIM signing domain as related to email- 
addresses within the same domain.  This relationship forms a basis for  
trusting email-address domains.  Defining signing domains as  
representing only abstract tokens unrelated to email-address domains  
negates a reasonable relationship, especially when an email-address  
has been specifically asserted to represent on whose behalf the  
signature was added.

>  A random bad actor, out there in the wilds of the Internet, cannot  
> use that SDID.

Without a relationship between a signing domain and the email-address  
domain, then whether a signing domain might be controlled by a bad  
actor will not be obvious.  Protection from bad actors appearing to  
control a domain _depends_ upon there being a relationship between  
signing domain and email-address domain.

> This is the core benefit of DKIM.

Not after the errata.

> Then there is the question of controlling different employees,  
> within the organization that owns the SDID.  Perhaps I'm authorized  
> to do signing, but the janitor in my organization isn't.
>
> Should a receiver that is validating a signature be asked to take on  
> the burden of enforcing access rules within the signing organization?

When there is a relationship between the email-address domain and the  
signing domain, it is not a question of  who is authorized.  The  
concern is whether email-address domains are normally signed, and  
which messages that are not signed should receive greater scrutiny.

> Protecting against outside attacks is inherent in DKIM's goal.   
> Protecting against attacks or misbehaviors from within the domain  
> owner's own organization strikes me as an inappropriate shifting of  
> enforcement burden onto the recipient.

When this refers to whether an on-behalf-of identity _must_ be  
represented by a From email-address, then agreed.  This level of  
enforcement will not benefit recipients or senders.  This was done to  
limit the use of g-restricted keys.

On the other hand, the i= parameter should clarify whether a message  
stream is on behalf of a mailing-list, as denoted in the email-address  
found in the Sender header, instead of an email-address seen in the  
From.  There is likely different acceptance criteria for these message  
types.  An ability to differentiate similar message streams within an  
email-address domain will be lost by describing the i= as representing  
an abstract token unrelated to the domain's email-addresses within  
signed headers. :^(

> If the working group agrees, then we have an opportunity to simplify  

Simplification is needed in ADSP, not DKIM.

> Similarly, there are some features that aren't getting used, and  
> that are not showing any signs of getting used.  Dropping them also  
> permits making DKIM substantially simpler.

DKIM has yet to be heavily relied upon, so which features are being  
used may change.  This may take more time to develop.

-Doug