Doug,
Is this meant to be recorded in the tracker? If so, then you
forgot to say "New issue" and so Eliot will likely skip over it.
Also, I should of course have said that the WG can only really
decide things that are decidable. So issues in the tracker really
need to have a proposed resolution or else I confidently expect
that they won't achieve rough consensus. We no longer want to
have open-ended discussions on ssp-reqs, its now time to start
making decisions.
This mail falls on both hurdles IMO.
So, if you do want these points considered, send a new mail that
Eliot will notice and if at all possible include a proposed
resolution (or else say why you cannot).
Stephen.
Douglas Otis wrote:
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