Doug,
Thanks for taking the time to make a concrete proposal. However: a) I would be very surprised if that text gained consensus due to its serious lack of clarity (sorry to be critical, but there it is), b) there doesn't seem to be anything new there, but its hard to know given (a). Regards, Stephen. Douglas Otis wrote:
A follow on: Suggested text for a trust section. This section is rather long, but several DKIM specific threat concerns were not previously covered. 5. Retaining Trust with DKIM Signatures A required retention of trust by an email source protects email's utility as an efficient form of communication. Often "block-listing" is a method of ostracism used for email sources that have been identified as violating a trust. Email sources being block-listed often have not adhered to an "opt-in" criteria for the distribution of bulk email. With DKIM, the message envelope is excluded from the message signature for compliance with the SMTP store-and-forward delivery strategy. Therefore, a DKIM signature precludes an assessment of the number, the return-path, and the intended recipients associated with the signing domain of a message. Omission of the message envelope therefore necessitates a different evaluation paradigm than that of a typical "opt-in" criteria when assessing the trustworthiness of the signing-domain. The DKIM signature offers no assurances related to number of messages, the intended recipients, or the return-path, which are often criteria used to assess abusive email sources. The assurance provided by the verification of the DKIM signature is limited to the domain of the initial email source and the encompassed message content. Regardless of the number of messages, and those sent to recipients that never expressed a desire for their receipt, such behavior can not be attributed to the signing domain. The assurance provided by the DKIM signature is strictly limited to the initial domain and the nature of the message's content. Messages of a criminal nature, encompassing a deceptive header field, or offering misleading links provides the limited basis for assessing a violation of trust. Evaluating a message's content compared to the message's initial domain represents both a labor and computer intensive process. Nevertheless, a DKIM signature should reduce the errors involved with such an evaluation of individual messages. Following a message evaluation, 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 will be unable to respond fast enough to deter abuse of a "trusted" message status. 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 is 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. Retaining trust demands extremely stringent control of all messages which may receive an assurance of trust. Even one signed message can be replicated a billion-fold and sent rapidly anywhere by an army of zombie computers. Not all users sending messages from an email-address domain may be trustworthy enough to meet the stringent requirements needed for retaining trust. There should be a method, perhaps with a flag within the DKIM key, to indicate whether the signing domain itself considers the source of the message to be trustworthy. This trust assertion mechanism would 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 an assurance of trust to the recipient unless overridden by a local database maintained by the recipient. A signing domain may consider private keys within traveling employee's laptop at too great of risk to allow the key to be evaluated as trustworthy. When the private key becomes stolen, until discovered, and for as long as the TTL of the key allowed retention within a cache, a bad actor could send deceptive messages creating significant damages, especially when assurances of trustworthiness are being relied upon. In the case of the traveling employee while away from the office, their messages would not be marked as trustworthy. However, the same employee and associated email-address could be marked as trustworthy when sent from the office. 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 a trusted/non-trusted key would permit the signing domain to both retain their trustworthy status and other users within the same domain would be unable to spoof their own customers with "trusted" messages. In addition to the MDA marking messages as "trusted", the recipient's MUA could also perform a similar function based upon a locally maintained list of trustworthy sources. This locally maintained list could include additional information beyond just the domain name itself to elevate the level of trust for specific email sources. This additional information may relate to the account used to access the signing domain and possibly the purported role of the signing domain. Sources for this locally maintained list would be confirmed by some out-of-band method. Without the purported role of the signing domain noted within the signature, maintenance of a local list would likely involve the nuisance of resolving apparent conflicts when the same email-address appears from both MSAs and mediators, such as list-servers. 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 having unique signatures sent to specific recipients. When message replay abuse becomes problematic, the recipient involved could be excluded in the future from receiving "trusted" messages as one possible preventative. With the high cost of evaluation and the inability to associate the message envelope information with the signing domain, there should be no expectation whatsoever that DKIM offers a means to abate common spam. A white- list of signing domains should not cause a bypassing of normal checks for messages using keys not also marked as "trusted". -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
_______________________________________________ ietf-dkim mailing list http://dkim.org
