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
