ietf-dkim
[Top] [All Lists]

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

2009-03-20 17:03:55

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

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.

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  
DKIM.

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

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>