[ietf-dkim] 5 outstanding issues with the threat review

As other avenues close, the Signing-Domain's Administrative Unit  
represents a primary area of concern not properly considered in the  
threat draft.
1) Access in the Signing-Domain's Administrative Unit

Bad actors in the form of rogue or unauthorized users or malware- 
infected computers can exist within the administrative unit  
corresponding to a message's origin address.  Although the submission  
of messages in this area generally occurs prior to the application of  
a message signature, DKIM can offer a means to detect and implement  
controls against these bad actors; see Opaque-ID.


2) Chosen Message Replay (High impact)

The rapid pace at which the message might be replayed (especially  
with an army of "zombie" computers), compared with the time required  
to detect the attack and implement key revocation, is likely to be  
ineffectual.  A related problem is the likelihood that domains will  
use a small number of signing keys for a large number of customers,  
where key revocation will also result in collateral blocking of  
messages.
At the extreme, verifiers might be required to check a listing for  
each signature verified, which would result in significant  
transaction rates.  An alternative, "revocation identifiers", has  
been proposed which would permit revocation on an intermediate level  
of granularity, perhaps on a per-account basis. Messages containing  
these identifiers would result in a query to a revocation database,  
which might be represented in the sender's DNS.
Primarily due to many users having compromised systems, block-lists  
still permit a substantial amount of email abuse to be emitted from  
large domains. Block-listing large domains remains problematic, as  
this often interferes with millions of user messages.  Often larger  
domains apply rate-limiting to keep this abuse from exceeding a  
reasonable portion of the overall messages. These abusive messages  
are however a ready source of signed messages that could enable  
chosen message replay abuse. Similar sources of signed messages could  
be obtained from email-address providers or list-servers, as there is  
_no_ practical means to vet individuals for low cost or often free  
services.  One motivation for chosen message replay abuse would be to  
evade typical rate restrictions while having the message appear to be  
from a respected source.
Opaque-ID:

By including a persistent identifier within the signature header  
field, the specific source of abuse emerging from signing domains can  
be identified and succinctly reported.  With this identifier, the  
signing-domain would also be able to self block-list or revoke these  
internal sources without requiring the expiry of a key TTL, or  
consuming large amounts of DNS cache.  The self block-list would also  
provide essential feedback to a reputation service that actions were  
taken, as the replay abuse may still persist.  A reputation service  
must be responsive to their subscribers who will demand that  
excessive amounts of abuse be blocked.
A convention could be established where immediate acceptance of a  
message requires that the HELO be verified and associated with the  
signing-domain.  Otherwise, delayed acceptance permits the needed  
time for a third-party or self block-listing of abusive sources.  The  
stability of the DNS is highly indicative of abusive behaviors.  The  
DNS is succinctly identified when the HELO is verified.


(Cisco is recommending Sender-ID with DKIM.  This recommendation may  
create conflicts when dealing with the topic of DKIM DoS  
susceptibility.)
3) Increased Threats Due to Expedient Assessments (Why replay abuse  
has a HIGH impact)
Bad acts related to the message envelope represents a potential  
threat when the signing-domain is held liable for these acts.  A  
forward referenced DNS PTR list of HELO domains minimizes any  
impact.  The alternative of having each node of an SMTP message from  
anonymous clients potentially trigger SPF script's maximals of 122  
DNS transactions (100) from foreign domains, when evaluating _each_  
message related domain-name, must be strongly discouraged.  SMTP  
readily distributes an SPF trigger to cascade targeted UDP traffic  
and enable various dangerous attacks and exploits.  Fortunately, HELO  
verification only needs one lookup and can not lead to targeted  
network amplification.  When the HELO is within the signing domain,  
even a lookup of the HELO domain list in the signing domain can be  
skipped.  The worst case DNS traffic amplification for a forward  
reference PTR HELO list is 1 DNS transaction for a known and accepted  
sending-system.  There is _no_ means to defend the alternative  
practice that executes script from anonymous clients which  
sequentially invokes hundreds of DNS transactions per SMTP node.


4) Risks of Confusion Using Sub-domains

Not all users or sources sending messages within an email-address  
domain may be trustworthy enough to meet stringent requirements  
needed for retaining trust. There is also often a desire to retain  
current email-address assignments and also claim all messages from a  
domain are signed.  Without a means to group the trustworthiness of  
various email sources within a domain, the overall trustworthiness of  
the domain is significantly diminished.  There should be a method,  
perhaps with a tag within the DKIM key, to indicate whether the  
signing domain itself considers the source of the message  
trustworthy.  This trust assertion mechanism could provide a means  
for a domain to retain their trustworthy assessment, while still  
signing all messages.  Messages sent from trustworthy domains, but  
where the key is not also marked trustworthy, should not convey  
assurances to the recipient unless overridden by a local database  
maintained by the recipient.
Providers offering low cost or free services will not be able to  
adequately vet their many users, who often number in the millions.   
This same provider may wish to send messages from the same domain and  
have these messages receive a trustworthy evaluation.  Perhaps these  
would be messages from a system administrator indicating that the  
user's system appears compromised or that their payment information  
is no longer valid.  The use of trusted/non-trusted keys would permit  
the signing domain to both retain their trustworthy status and  
prevent un-vetted users within the same domain from spoofing with  
"trusted" messages.


5) Preventing Spoofs from Untrusted Sources (Signing roles needed)

In addition to the MDA marking messages as "trusted" based upon the  
history of a domain's behavior and the status of the key, the  
recipient's MUA could also perform a similar function using a locally  
maintained list of trustworthy sources. The locally maintained list  
could include additional information beyond just the domain name  
itself to elevate the level of trust for specific email sources, even  
when not indicated as trustworthy by the signing domain. This  
additional information might relate to the account used to access the  
signing domain and possibly the purported role of the signing domain.  
Out-of-band source confirmation would be needed for a locally  
maintained list. Without a purported role of the signing-domain being  
noted, maintenance of a local list would become a nuisance resolving  
conflicts when the same email-address appears from both MSAs and  
mediators.
-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html