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