diff options
Diffstat (limited to '_doc/RFC_4686__DKIM_THREATS.adoc')
| -rw-r--r-- | _doc/RFC_4686__DKIM_THREATS.adoc | 268 |
1 files changed, 268 insertions, 0 deletions
diff --git a/_doc/RFC_4686__DKIM_THREATS.adoc b/_doc/RFC_4686__DKIM_THREATS.adoc new file mode 100644 index 00000000..54bf6c08 --- /dev/null +++ b/_doc/RFC_4686__DKIM_THREATS.adoc @@ -0,0 +1,268 @@ +// SPDX-License-Identifier: BSD-3-Clause +// SPDX-FileCopyrightText: 2019 M. Shulhan <ms@kilabit.info> + += Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) +:toc: +:sectnums: +:sectlinks: +:url-rfc4686: https://tools.ietf.org/html/rfc4686 + +This document provide note and summary of +{url-rfc4686}[RFC 4686^], Analysis of Threats Motivating DomainKeys Identified +Mail (DKIM). + + +== Introduction + +The DKIM protocol defines a mechanism by which email messages can be +cryptographically signed by Message Submission Agent (MSA) based on domain +name. +Recipients then can verify the signature by querying the signer's domain +directly to retrieve the appropriate public key, and thereby confirm that the +message was attested to by a party in possession of the private key for the +signing domain. + +=== Terminology and Model + +An administrative unit (AU) is the portion of the path of an email message +that is under common administration. + +The following diagram illustrates a typical usage flowchart for DKIM: + +.... + +---------------------------------+ + | SIGNATURE CREATION | + | (Originating or Relaying AU) | + | | + | Sign (Message, Domain, Key) | + | | + +---------------------------------+ + | - Message (Domain, Key) + | + [Internet] + | + V + +---------------------------------+ + +-----------+ | SIGNATURE VERIFICATION | + | | | (Relaying or Delivering AU) | + | KEY | | | + | QUERY +--->| Verify (Message, Domain, Key) | + | | | | + +-----------+ +----------------+----------------+ + | - Verified Domain + +-----------+ V - [Report] + | SENDER | +----------------+----------------+ + | SIGNING | | | + | PRACTICES +--->| SIGNER EVALUATION | + | QUERY | | | + +-----------+ +---------------------------------+ +.... + +DKIM operates entirely on the content (body and selected header fields) of the +message. + +The following definitions were used as rough criteria for scoring the attacks: + +* Impact: +** High: Affects the verification of messages from an entire domain or +multiple domains +** Medium: Affects the verification of messages from specific users, Mail +Transfer Agents (MTAs), and/or bounded time periods +** Low: Affects the verification of isolated individual messages only + +* Likelihood: +** High: All email users should expect this attack on a frequent basis +** Medium: Email users should expect this attack occasionally; frequently for +a few users +** Low: Attack is expected to be rare and/or very infrequent + +== The Bad Actors + +The bad actors are expected to have access to the following: + +* An extensive corpus of messages from domains they might wish to impersonate +* Knowledge of the business aims and model for domains they might wish to +impersonate +* Access to public keys and associated authorization records associated with +the domain + +The bad actors are expected to be able to, + +* Submit messages to MTAs MSAs at multiple locations in the Internet + +* Construct arbitrary message header fields, including those claiming to be +mailing lists, resenders, and other mail agents + +* Sign messages on behalf of domains under their control + +* Generate substantial numbers of either unsigned or apparently-signed +messages that might be used to attempt a denial-of-service attack + +* Resend messages that may have been previously signed by the domain + +* Transmit messages using any envelope information desired + +* Act as an authorized submitter for messages from a compromised computer + +* Manipulation of IP routing. +This could be used to submit messages from specific IP addresses or +difficult-to-trace addresses, or to cause diversion of messages to a specific +domain. + +* Limited influence over portions of DNS using mechanisms such as cache +poisoning. +This might be used to influence message routing or to falsify advertisements +of DNS-based keys or signing practices. + +* Access to significant computing resources, for example, through the +conscription of worm-infected "zombie" computers. +This could allow the bad actor to perform various types of brute-force +attacks. + +* Ability to eavesdrop on existing traffic, perhaps from a wireless network. + +=== Location + +The bad actors can reside inside the AU or outside the AU. + +External bad actors usually try to send unwanted message to local +mailbox, either without signature, with incorrect signature, or valid +signature. + +When the bad actors come from inside, DKIM is not directly effective because +the signature is generated after the message has been submitted. +One of defense againts internal bad actors is by applying authentication to +MSA. + + +== Representative Bad Acts + +One of the most fundamental bad acts being attempted is the delivery +of messages that are not intended to have been sent by the alleged +originating domain. + +=== Use of Arbitrary Identities + +DKIM is not effective against the use of addresses controlled by bad actors. + +Accreditation and reputation systems and locally-maintained whitelists and +blacklists can be used to enhance the accountability of DKIM-verified +addresses and/or the likelihood that signed messages are desirable. + +=== Use of Specific Identities + +DKIM is not effective against the domains controlled by bad actors. + +DKIM is effective against the use of specific identities only when +there is an expectation that such messages will, in fact, be signed. +The primary means for establishing this is the use of Sender Signing +Practices (SSP). + +==== Exploitation of Social Relationships + +DKIM could be effective in mitigating these acts by limiting the scope of +origin addresses for which a valid signature can be obtained when sending the +messages from other locations. + +==== Identity-Related Fraud + +DKIM is effective in defending against the fraudulent use of origin addresses +on signed messages. +When the published sender signing practices of the origin address indicate +that all messages from that address should be signed, DKIM further mitigates +against the attempted fraudulent use of the origin address on unsigned +messages. + +==== Reputation Attacks + +It is for this reason that reputation systems must be based on an identity +that is, in practice, fairly reliable. + +==== Reflection Attacks + +It is common and useful practice for a message's return path not to correspond +to the origin address. +For these reasons, DKIM is not effective against reflection attacks. + + +== Attacks on Message Signing + +=== Attacks against Message Signatures + +The following is a summary of postulated attacks against DKIM signatures: + +[cols=".<8,.^1,.^1"] +---- +|=== +| Attack Name | Impact | Likelihood + +| Theft of private key for domain | High | Low +| Theft of delegated private key | Medium | Medium +| Private key recovery via side channel attack | High | Low +| Chosen message replay | Low | Medium/High +| Signed message replay | Low | High +| Denial-of-service attack against verifier | High | Medium +| Denial-of-service attack against key service | High | Medium +| Canonicalization abuse | Low | Medium +| Body length limit abuse | Medium | Medium +| Use of revoked key | Medium | Low +| Compromise of key server | High | Low +| Falsification of key service replies | Medium | Medium +| Publication of malformed key records and/or signatures | High | Low +| Cryptographic weaknesses in signature generation | High | Low +| Display name abuse | Medium | High +| Compromised system within originator's network | High | Medium +| Verification probe attack | Medium | Medium +| Key publication by higher-level domain | High | Low +|=== +---- + +=== Attacks against Message Signing Practices + +The following is a summary of postulated attacks against signing +practices: + +[cols=".<8,.^1,.^1"] +---- +|=== +| Attack Name | Impact | Likelihood + +| Look-alike domain names | High | High +| Internationalized domain name abuse | High | High +| Denial-of-service attack against signing practices | Medium | Medium +| Use of multiple From addresses | Low | Medium +| Abuse of third-party signatures | Medium | High +| Falsification of Sender Signing Practices replies | Medium | Medium +|=== +---- + + +=== Other Attacks + +[cols=".<8,.^1,.^1"] +---- +|=== +| Attack Name | Impact | Likelihood + +| Packet amplification attacks via DNS | N/A | Medium +|=== +---- + +== Derived Requirements + +These requirements include: + +* The store for key and SSP records must be capable of utilizing multiple +geographically-dispersed servers. + +* Key and SSP records must be cacheable, either by the verifier requesting +them or by other infrastructure. + +* The cache time-to-live for key records must be specifiable on a per-record +basis. + +* The signature algorithm identifier in the message must be one of the ones +listed in a key record for the identified domain. + +* The algorithm(s) used for message signatures need to be secure against +expected cryptographic developments several years in the future. |