返回首页

RFC 4686 - Analysis of Threats Motivating DomainKeys Identif

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup J.Fenton RequestforComments:4686CiscoSystems,Inc. Category:Informational September2006 AnalysisofThreatsMotivatingDomainKeysIdentifiedMail(DKIM) StatusofThisMemo ThismemoprovidesinformationfortheInternetcommunity.Itdoes notspecify
  Network Working Group                                               J. Fenton
Request for Comments: 4686                           Cisco Systems, Inc.
Category: Informational                                        September 2006

    Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides an analysis of some threats against Internet
   mail that are intended to be addressed by signature-based mail
   authentication, in particular DomainKeys Identified Mail.  It
   discusses the nature and location of the bad actors, what their
   capabilities are, and what they intend to accomplish via their
   attacks.

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology and Model ......................................3
      1.2. Document Structure .........................................5
   2. The Bad Actors ..................................................6
      2.1. Characteristics ............................................6
      2.2. Capabilities ...............................................6
      2.3. Location ...................................................8
           2.3.1. Externally-Located Bad Actors .......................8
           2.3.2. Within Claimed Originator’s Administrative Unit .....8
           2.3.3. Within Recipient’s Administrative Unit ..............9
   3. Representative Bad Acts .........................................9
      3.1. Use of Arbitrary Identities ................................9
      3.2. Use of Specific Identities ................................10
           3.2.1. Exploitation of Social Relationships ...............10
           3.2.2. Identity-Related Fraud .............................11
           3.2.3. Reputation Attacks .................................11
           3.2.4. Reflection Attacks .................................11
   4. Attacks on Message Signing .....................................12
      4.1. Attacks against Message Signatures ........................12
           4.1.1. Theft of Private Key for Domain ....................13
           4.1.2. Theft of Delegated Private Key .....................13
           4.1.3. Private Key Recovery via Side Channel Attack .......14
           4.1.4. Chosen Message Replay ..............................14
           4.1.5. Signed Message Replay ..............................16
           4.1.6. Denial-of-Service Attack against Verifier ..........16
           4.1.7. Denial-of-Service Attack against Key Service .......17
           4.1.8. Canonicalization Abuse .............................17
           4.1.9. Body Length Limit Abuse ............................17
           4.1.10. Use of Revoked Key ................................18
           4.1.11. Compromise of Key Server ..........................18
           4.1.12. Falsification of Key Service Replies ..............19
           4.1.13. Publication of Malformed Key Records
                   and/or Signatures .................................19
           4.1.14. Cryptographic Weaknesses in Signature Generation ..20
           4.1.15. Display Name Abuse ................................21
           4.1.16. Compromised System within Originator’s Network ....21
           4.1.17. Verification Probe Attack .........................21
           4.1.18. Key Publication by Higher-Level Domain ............22
      4.2. Attacks against Message Signing Practices .................23
           4.2.1. Look-Alike Domain Names ............................23
           4.2.2. Internationalized Domain Name Abuse ................23
           4.2.3. Denial-of-Service Attack against Signing
                  Practices ..........................................24
           4.2.4. Use of Multiple From Addresses .....................24
           4.2.5. Abuse of Third-Party Signatures ....................24
           4.2.6. Falsification of Sender Signing Practices Replies ..25

      4.3. Other Attacks .............................................25
           4.3.1. Packet Amplification Attacks via DNS ...............25
   5. Derived Requirements ...........................................26
   6. Security Considerations ........................................26
   7. Informative References .........................................27
   Appendix A. Acknowledgements ......................................28

1.  Introduction

   The DomainKeys Identified Mail (DKIM) protocol is being specified by
   the IETF DKIM Working Group.  The DKIM protocol defines a mechanism
   by which email messages can be cryptographically signed, permitting a
   signing domain to claim responsibility for the use of a given email
   address.  Message recipients 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.  This document
   addresses threats relative to two works in progress by the DKIM
   Working Group, the DKIM signature specification [DKIM-BASE] and DKIM
   Sender Signing Practices [DKIM-SSP].

   Once the attesting party or parties have been established, the
   recipient may evaluate the message in the context of additional
   information such as locally-maintained whitelists, shared reputation
   services, and/or third-party accreditation.  The description of these
   mechanisms is outside the scope of the IETF DKIM Working Group
   effort.  By applying a signature, a good player enables a verifier to
   associate a positive reputation with the message, in hopes that it
   will receive preferential treatment by the recipient.

   This effort is not intended to address threats associated with
   message confidentiality nor does it intend to provide a long-term
   archival signature.

1.1.  Terminology and Model

   An administrative unit (AU) is the portion of the path of an email
   message that is under common administration.  The originator and
   recipient typically develop trust relationships with the
   administrative units that send and receive their email, respectively,
   to perform the signing and verification of their messages.

   The origin address is the address on an email message, typically the
   RFC 2822 From: address, which is associated with the alleged author
   of the message and is displayed by the recipient’s Mail User Agent
   (MUA) as the source of the message.

   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, as defined in RFC 2822 [RFC2822].  The
   transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
   such elements as the envelope-from and envelope-to addresses and the
   HELO domain are not relevant to DKIM verification.  This is an
   intentional decision made to allow verification of messages via
   protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
   which an MUA acting as a verifier might use.

   The Sender Signing Practices Query referred to in the diagram above
   is a means by which the verifier can query the alleged author’s
   domain to determine their practices for signing messages, which in
   turn may influence their evaluation of the message.  If, for example,
   a message arrives without any valid signatures, and the alleged
   author’s domain advertises that they sign all messages, the verifier
   might handle that message differently than if a signature was not
   necessarily to be expected.

1.2.  Document Structure

   The remainder of this document describes the problems that DKIM might
   be expected to address, and the extent to which it may be successful
   in so doing.  These are described&nb