[ietf-dkim] requrements-01// security concerns regarding policy
domain designations rather than delegations
stephen.farrell at cs.tcd.ie
Mon Sep 18 06:53:46 PDT 2006
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
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).
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
> - Annotation of a recognized email-address based upon recipient
> - 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?
More information about the ietf-dkim