The assessments made in the threat review indicate a high impact
threat affects the entire domain, and a medium impact affects
specific users, and MTAs. (A literalistic description of threat is
"message classification subsequent to verification.")
Avoiding a domain-wide threat appears essential for preventing a high
impact so...
How does DKIM ensure the scope of a threat is limited to specific users?
------------------------------------------------------------------------
Assuming the message is signed, when is a recipient assured that
classifications based upon the email-address will provide a practical
means to curtail abuse?
An assurance might be implied when the i= or g= parameter contain the
local-part of the email-address. There are no low impact threats
without the i= or g= local-part, as there would be few reasons for
the recipient to limit the scope of their message classifications.
The number of potential email-addresses is unlimited, and a selective
recipient will need to expend far greater resources to assess each
email-address individually, rather than at the signing domain.
When an i= or g= local-part is not used, classifications will likely
be domain-wide, where all related threats become high impact. There
is no means to assure a recipient that classifications based upon the
signature s= parameter provides a practical means to curtail abuse,
and thus limit the threat impact. As such, how can DKIM limit the
scope of a threat to a specific MTA? There would need to be some
means to assure the recipient that the associated s= key selector
provides a practical means to curtail abuse, rather than the simpler
method of classifying messages based upon the signing domain.
When a provider does not restrict the use of an email-address, any
and all threats will therefore affect the signing-domain as a whole,
and will produce a high impact. Without recipients individually
evaluating each email-address within a domain, and consumers of a
signing domain being restricted to specific email-addresses, all
classifications will likely be domain-wide and will create a high
impact when abuses such as message replay occur. The domain-wide
impact of this abuse will also affect messages being annotated to
convey greater trust.
Even a very large domain may not enjoy their normal accommodations
that overlook a small percentage of abuse, as the signing domain will
not have the ability to effectively rate limit messages classified by
a signing domain. A need to assert that all messages are signed to
achieve non-repudiation protections creates a quandary. The only
solution currently available would be to place messages from less
vetted sources into different domains. This would be disruptive and
confusing for recipients.
One method that can be used to limit the scope of the threat would be
to employ the r= parameter. The three categories created by the r=
parameter require far less resources than assessing each email-
address separately. When a small subset of messages convey critical
information, isolating this information with an r=1 requires less
effort than restricting all email-addresses. In addition, message
annotations would not depend upon the recipient recognizing the email-
address, which are often unknown email-addresses like do-not-
replay(_at_)(_dot_) The r= parameter limits the scope of the threat. This
could be valuable when the signing domain is only interested in
retaining trust for a category of messages, independent of email-
addresses and any email-address use restrictions.
With the r= approach, the average consumer does not need to hear they
can no longer use their email-address. With the r= approach, the
average recipient is safer and better protected.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html