[ietf-dkim] Delegation and Designation (#1360)
dotis at mail-abuse.org
Fri Sep 29 01:25:45 PDT 2006
On Thu, 2006-09-28 at 22:19 -0700, Jim Fenton wrote:
> So the question is, do we need both delegation and designation?
> My opinion, if it isn't already obvious from the above discussion, is
> that designation is a flawed way of delegating signing authority. I
> don't like the fact that example.com can hire exampletwo.com to send out
> a bunch of bulk advertising, and then when there are objections,
> effectively finger-point and say "Exampletwo did it". If example.com
> wants mail sent by exampletwo.com to be treated as if it came from them
> (first-party signature), they should be willing to take responsibility
> for it themselves. If they don't want to take that responsibility, they
> should accept that exampletwo.com applies a third-party signature.
The delegation process may be the provider routinely offering public
keys to their customers for publishing at specific locations, or the
customer delegating zones at or below their "_domainkey" label to one or
more providers. This delegation process represents an undesirable level
of complexity involving a significant amount of detail among several
entities when it can be avoided.
Beyond the complexity, delegation in this manner has other significant
down-sides. You allude to DKIM being used for reputation, but it
remains conjecture whether a digital signature that does not identify
the SMTP Client, and can not prevent replay abuse is even suitable as a
basis for conventional email reputation. Trust is a differ matter
discussed further down.
What is not conjecture is that DKIM will facilitate abuse reporting to
the signing domain, and that IP based reputation will remain the
predominate basis for conventional email reputation for sometime. Here
DKIM allows the provider noise-free abuse feedback. They are sure to be
informed of damage a customer may be causing to their IP address
reputation. With DKIM, what is sure to matter is who should be informed
and receiving abuse feedback. Reputation is likely based upon
unsolicited bulk messages where DKIM offers no assurance of even
indicating who might be at fault.
Another concern is easily as serious is that of trust. When a provider
does not adequately safeguard account access, or properly secure systems
filled with "other people's private keys," there can be significant
damage created for the email-address domain owner when messages of a
criminal or highly questionable nature receive their signature, while
they have never seen the content or have logs of what and to whom.
As for designation-
The draft that was just published illustrates two different signing
roles can be designated, also accompanied with local-part constraints.
All the same features, but with far less effort. One role would be that
of a domain only offering valid signatures, but without the
email-address being assured valid. This would be roughly equivalent to
a signature lacking the 'i=' parameter while still fulfilling an "All
Messages Are Signed" assertion.
Another designated role could operate in virtually the same manner as
that of delegation. Rather than matching keys with accounts, the
provider would match email-address domains with accounts. Rather than
establishing a complex delegation process, the account would validate
control of the email-address being used. This validation process can be
automated and is fairly common in many other applications already.
By using a designation process, the email-address domain owner controls
assertions regarding the validity of the email-address. A provider
might be used for less critical communications where delivery is of
greater importance. Consider that DKIM offers scant protections without
annotations. These annotations should permit the recognition of valid
sources, AND valid email-addresses.
More information about the ietf-dkim