[ietf-dkim] requrements-01// security concerns regarding policy domain designations rather than delegations

[Stephen Farrell]

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
>