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