Re: [ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

Based upon the feedback offered by Frank, this section has been  
revised to offer more concise statements related to threats.  As  
Frank and Jim have pointed out, other concurrent strategies may be  
needed to defend DKIM when used as a basis for acceptance.  This  
review focused upon the scope of the message used to assess bad acts,  
and explored risks related to those aspects of the message not  
protected by the DKIM signature.  This reviews defensive strategies  
using message envelope and DKIM based information.
----


5. Signing Domains Retaining Trust

The required retention of trust by an identified email source  
protects email's utility as an efficient form of communication. The  
signing domain offers a verified identifier that can be used to  
accrue a history of behavior, as mentioned in the introduction. A  
DKIM signature excludes the message envelope, and thus precludes an  
equitable assessment of the signing domain based upon the number of  
messages, return-path, or recipients. Bad acts verifiably associated  
with the signing domain are therefore limited to the message content,  
such as encompassed deceptive header fields, malware, or dangerously  
misleading information or links.
5.1 Verifiable Assessments are Resource Intensive

Assessing message content is extremely resource intensive, when  
compared to the typical “opt-in” criteria often used to establish  
most block-lists. Assessing verifiable actions of the signing domain  
might be slow and involve human interaction across hundreds of  
languages. Such absorbent efforts in assessing the actions of signing- 
domains may cause some recipients to instead hold the signing domain  
liable for bad acts determined by the unsigned message envelope. This  
highly probable expediency increases the signing-domain's exposure to  
reputation attacks, as even stringent control of message content will  
not offer protection.
5.2 Increased Threats Due to Expedient Assessments

Bad acts related to the message envelope represents a potential  
threat when the signing-domain is held liable for these acts. Path  
registration may play a role in defending against this threat. When  
based upon the return-path, there is no overlapping information to  
offer protection for a DKIM message. An alternative to the return- 
path is the Purported Responsible Address (PRA), a licensed algorithm  
with terms some find unsatisfactory. For the signing domain to retain  
source control using PRA path registration, the mediator provisions  
of PRA modified [RFC2822] Resent-* header fields, as well as Sender  
header fields, must be blocked by DKIM listing non-existent headers  
as part of the signature.
PRA path registration with the mediator provisions blocked might  
prevent a bad actor from staging a replay attack, but then email that  
would normally pass through a PRA compliant mediator would be blocked  
as well. Not blocking the PRA mediator provisions however allows a  
bad actor to replay signed messages from a domain they control, and  
still leaves the signing domain exposed to possible message envelope  
liabilities.
An alternative to PRA path registration with header blocking,  
validating the same portion of the DKIM message path, would be a  
forward referenced DNS PTR list of HELO domains. The maximal 112 DNS  
lookups that might be needed to compile a PRA path also introduces  
significant susceptibility to various attacks. Fortunately, HELO  
verification needs only one lookup. When the HELO is within the  
signing domain, even the lookup of a HELO list in the signing domain  
is skipped.
5.2.1 Delayed Lookup and Transient Negative Completion

A possible strategy that can be used when a path is not validated,  
would be to delay the lookup of a block-list based upon message  
envelope identifiers, or a revocation record published by the signing  
domain. This delay would be done in conjunction with "Requested  
action aborted: error in processing" SMTP response, See [RFC2821],  
and Section 4.1.4 Paragraph 5. Although message envelope assessments  
can be made rapidly, distributing these assessments still requires  
time. A delay in acceptance would allow time for an abusive replay to  
be discovered and the message envelope identifiers block-listed or a  
revocation record published.
A receiving domain may eliminate the delayed acceptance once the  
source is proven trustworthy. This strategy would provide protection  
from threats related to abusive message replay, and yet still allow  
messages to transverse mediators. Using revocation records rather  
than block-listing message envelope identifiers assures the signing  
domain greater control of this protection. Distributing revocation  
information also offers greater overall reliability and robustness  
from attack.
5.3 Threats Related to Assessment Delays

Owing to the extensive resources and time needed to properly evaluate  
DKIM related bad acts, any resulting assurances conveyed to the  
recipient should preclude those messages from unknown signing domains  
which might be controlled by a bad actor. Rather than presuming a  
domain is trustworthy until proven otherwise as with block-listing, a  
vetted list of trusted signing domains should qualify assurances  
conveyed to the recipient. A reputation system may be unable to  
respond fast enough to deter the abuse of message related assurances.
A safe indication conveyed to a recipient would be an assurance that  
a message source is from a "trusted" signing domain. An indication  
that an email-address happens to be within a signing domain can be  
accomplished by any bad actor controlling a signing-domain. Any email- 
address related assurances would dangerously presume the recipient is  
capable of a rather perilous examination of the email-address, and  
also that the recipient has knowledge of the domain name hierarchy.
5.4 Trustworthy Assertions
5.4.1 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.4.2 Preventing Spoofs from Untrusted Sources

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.
5.5 The Risk of Overwhelming the Assessment Process

Due to the cost related to evaluating a DKIM signing domain's  
violation of trust, the use of "trusted" keys should be limited to  
transactional messages, ideally having unique signatures sent to  
specific recipients. With the high cost of evaluation and the  
inability to verify the association of the message envelope  
information with the signing domain, there should be no expectation  
whatsoever that DKIM offers a means to abate common spam, or that  
assessments can be based upon an unlimited number of email-addresses  
and signatures. A white-list of signing domains should not cause the  
bypassing of normal checks for messages using keys not also marked as  
"trusted".
-Doug


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