This document raises concerns regarding the security of designations
rather than delegations. A designation approach does not relinquish
control of domain signing, or imperil the sending agent or the email-
address domain with having administered the signing of messages by a
different domain. The domain actually sending the messages using
another domain's keys is imperiled by not seeing abuse reports sent
to the foreign signing domain.
As DKIM is unrelated to the message envelope, has no controls on
message replay or practical message revocation schemes, the use of
the signing domain as a basis for acceptance or rejection remains
highly problematic in the general case. Requiring the 2821.Rcpt To
to match a 2822.To or CC header field email-address is not practical.
A receiving domain might caution a signing domain, but without
knowing the source of a message has no ability to verify corrective
actions, or know when it might be safe to once again to use the
signing domain as a basis for acceptance. This problem is true for
nearly any large domain. Conversely, corrective actions may have
been taken and yet problems may persist due to the lack of source
information and the potential replay issues.
Any assumption that a DKIM signature can be used as a basis for
acceptance or rejection introduces very serious denial of service
issues. The primary goal of email-address policies should be aimed
at safely leveraging DKIM signatures. The DKIM signature does safely
permit the following when a signing domain has been designated by an
email-address:
- Annotation of a recognized email-address based upon recipient
retentions.
- Safe DSNs based upon 2821.Mail Froms.
- Reporting of abuse based upon the signing domain directed to
actionable and ultimately accountable entities.
There should be a general understanding of the futility and perils
using a DKIM signature as a sole basis of acceptance or rejection.
Some policies may identify suspicious messages, however reliance upon
identifying recognized messages offers greater protections without
potentially causing disruptions in email delivery. Abuse MUST be
handled by identifiers tracking the actual sending agent.
The requirements draft appears to overlook and misconstrue rather
serious security concerns. As this is a requirements document,
perhaps fundamental security concerns need to be understood and
agreed upon. What are the underlying security concerns related to
some email-address policy and how can security be generally improved
upon by this policy?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
