Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) :: RFC4870








Network Working Group                                          M. Delany
Request for Comments: 4870                                    Yahoo! Inc
Obsoleted By: 4871                                              May 2007
Category: Historic


          Domain-Based Email Authentication Using Public Keys
                   Advertised in the DNS (DomainKeys)

Status of This Memo

   This memo defines a Historic Document 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 IETF Trust (2007).

Abstract

   "DomainKeys" creates a domain-level authentication framework for
   email by using public key technology and the DNS to prove the
   provenance and contents of an email.

   This document defines a framework for digitally signing email on a
   per-domain basis.  The ultimate goal of this framework is to
   unequivocally prove and protect identity while retaining the
   semantics of Internet email as it is known today.

   Proof and protection of email identity may assist in the global
   control of "spam" and "phishing".



















Delany                          Historic                        [Page 1]

RFC 4870                       DomainKeys                       May 2007


Table of Contents

   1. Introduction ....................................................3
      1.1. Lack of Authentication Is Damaging Internet Email ..........3
      1.2. Digitally Signing Email Creates Credible Domain
           Authentication .............................................4
      1.3. Public Keys in the DNS .....................................4
      1.4. Initial Deployment Is Likely at the Border MTA .............5
      1.5. Conveying Verification Results to MUAs .....................5
      1.6. Technical Minutiae Are Not Completely Covered ..............5
      1.7. Motivation .................................................6
      1.8. Benefits of DomainKeys .....................................6
      1.9. Definitions ................................................7
      1.10. Requirements Notation .....................................8
   2. DomainKeys Overview .............................................8
   3. DomainKeys Detailed View ........................................8
      3.1. Determining the Sending Address of an Email ................9
      3.2. Retrieving the Public Key Given the Sending Domain ........10
           3.2.1. Introducing "selectors" ............................10
           3.2.2. Public Key Signing and Verification Algorithm ......11
           3.2.3. Public key Representation in the DNS ...............13
           3.2.4. Key Sizes ..........................................14
      3.3. Storing the Signature in the Email Header .................15
      3.4. Preparation of Email for Transit and Signing ..............17
           3.4.1. Preparation for Transit ............................18
           3.4.2. Canonicalization for Signing .......................18
                  3.4.2.1. The "simple" Canonicalization Algorithm ...19
                  3.4.2.2. The "nofws" Canonicalization Algorithm ....19
      3.5. The Signing Process .......................................20
           3.5.1. Identifying the Sending Domain .....................20
           3.5.2. Determining Whether an Email Should Be Signed ......21
           3.5.3. Selecting a Private Key and Corresponding
                  Selector Information ...............................21
           3.5.4. Calculating the Signature Value ....................21
           3.5.5. Prepending the "DomainKey-Signature:" Header .......21
      3.6. Policy Statement of Sending Domain ........................22
      3.7. The Verification Process ..................................23
           3.7.1. Presumption that Headers Are Not Reordered .........24
           3.7.2. Verification Should Render a Binary Result .........24
           3.7.3. Selecting the Most Appropriate
                  "DomainKey-Signature:" Header ......................24
           3.7.4. Retrieve the Public Key Based on the
                  Signature Information ..............................26
           3.7.5. Verify the Signature ...............................27
           3.7.6. Retrieving Sending Domain Policy ...................27
           3.7.7. Applying Local Policy ..............................27
      3.8. Conveying Verification Results to MUAs ....................27




Delany                          Historic                        [Page 2]

RFC 4870                       DomainKeys                       May 2007


   4. Example of Use .................................................29
      4.1. The User Composes an Email ................................29
      4.2. The Email Is Signed .......................................29
      4.3. The Email Signature Is Verified ...........................30
   5. Association with a Certificate Authority .......................31
      5.1. The "DomainKey-X509:" Header ..............................31
   6. Topics for Discussion ..........................................32
      6.1. The Benefits of Selectors .................................32
      6.2. Canonicalization of Email .................................33
      6.3. Mailing Lists .............................................33
      6.4. Roving Users ..............................................33
   7. Security Considerations ........................................34
      7.1. DNS .......................................................34
           7.1.1. The DNS Is Not Currently Secure ....................34
           7.1.2. DomainKeys Creates Additional DNS Load .............35
      7.2. Key Management ............................................35
      7.3. Implementation Risks ......................................35
      7.4. Privacy Assumptions with Forwarding Addresses .............35
      7.5. Cryptographic Processing Is Computationally Intensive .....36
   8. The Trial ......................................................36
      8.1. Goals .....................................................36
      8.2. Results of Trial ..........................................37
   9. Note to Implementors Regarding TXT Records .....................37
   10. References ....................................................37
      10.1. Normative References .....................................37
      10.2. Informative References ...................................38
      Appendix A - Syntax Rules for the Tag=Value Format .............39
      Acknowledgments ................................................40

1.  Introduction

   This document proposes an authentication framework for email that
   stores public keys in the DNS and digitally signs email on a domain
   basis.  Separate documents discuss how this framework can be extended
   to validate the delivery path of email as well as facilitate per-user
   authentication.

   The DomainKeys specification was a primary source from which the
   DomainKeys Identified Mail [DKIM] specification has been derived.
   The purpose in submitting this document is as an historical reference
   for deployed implementations written prior to the DKIM specification.

1.1.  Lack of Authentication Is Damaging Internet Email

   Authentication of email is not currently widespread.  Not only is it
   difficult to prove your own identity, it is impossible to prevent
   others from abusing your identity.




Delany                          Historic                        [Page 3]

RFC 4870                       DomainKeys                       May 2007


   While most email exchanges do not intrinsically need authentication
   beyond context, it is the rampant abuse of identity by "spammers",
   "phishers", and their criminal ilk that makes proof necessary.  In
   other words, authentication is as much about protection as proof.

   Importantly, the inability to authenticate email effectively
   delegates much of the control of the disposition of inbound email to
   the sender, since senders can trivially assume any email address.
   Creating email authentication is the first step to returning
   dispositional control of email to the recipient.

   For the purposes of this document, authentication is seen from a user
   perspective, and is intended to answer the question "who sent this
   email?" where "who" is the email address the recipient sees and "this
   email" is the content that the recipient sees.

1.2.  Digitally Signing Email Creates Credible Domain Authentication

   DomainKeys combines public key cryptography and the DNS to provide
   credible domain-level authentication for email.

   When an email claims to originate from a certain domain, DomainKeys
   provides a mechanism by which the recipient system can credibly
   determine that the email did in fact originate from a person or
   system authorized to send email for that domain.

   The authentication provided by DomainKeys works in a number of
   scenarios in which other authentication systems fail or create
   complex operational requirements.  These include the following:

      o forwarded email

      o distributed sending systems

      o authorized third-party sending

   This base definition of DomainKeys is intended to primarily enable
   domain-level authenticity.  Whether a given message is really sent by
   the purported user within the domain is outside the scope of the base
   definition.  Having said that, this specification includes the
   possibility that some domains may wish to delegate fine-grained
   authentication to individual users.

1.3.  Public Keys in the DNS

   DomainKeys differs from traditional hierarchical public key systems
   in that it leverages the DNS for public key management, placing
   complete and direct control of key generation and management with the



Delany                          Historic                        [Page 4]

RFC 4870                       DomainKeys                       May 2007


   owner of the domain.  That is, if you have control over the DNS for a
   given domain, you have control over your DomainKeys for that domain.

   The DNS is proposed as the initial mechanism for publishing public
   keys.  DomainKeys is specifically designed to be extensible to other
   key-fetching services as they become available.

1.4.  Initial Deployment Is Likely at the Border MTA

   For practical reasons, it is expected that initial implementations of
   DomainKeys will be deployed on Mail Transfer Agents (MTAs) that
   accept or relay email across administrative or organizational
   boundaries.  There are numerous advantages to deployment at the
   border MTA, including:

      o  a reduction in the number of MTAs that have to be changed to
         support an implementation of DomainKeys

      o  a reduction in the number of MTAs involved in transmitting the
         email between a signing system and a verifying system, thus
         reducing the number of places that can make accidental changes
         to the contents

      o  removing the need to implement DomainKeys within an internal
         email network.

   However, there is no necessity to deploy DomainKeys at the border as
   signing and verifying can effectively occur anywhere from the border
   MTA right back to the Mail User Agent (MUA).  In particular, the best
   place to sign an email for many domains is likely to be at the point
   of SUBMISSION where the sender is often authenticated through SMTP
   AUTH or other identifying mechanisms.

1.5.  Conveying Verification Results to MUAs

   It follows that testing the authenticity of an email results in some
   action based on the results of the test.  Oftentimes, the action is
   to notify the MUA in some way -- typically via a header line.

   The "Domainkey-Status:" header is defined in this specification for
   recording authentication results in the email.

1.6.  Technical Minutiae Are Not Completely Covered

   The intent of this specification is to communicate the fundamental
   characteristics of DomainKeys for an implementor.  However, some
   aspects are derived from the functionality of the openssl command
   [OPENSSL] and, rather than duplicate that documentation, implementors



Delany                          Historic                        [Page 5]

RFC 4870                       DomainKeys                       May 2007


   are expected to understand the mechanics of the openssl command,
   sufficient to complete the implementation.

1.7.  Motivation

   The motivation for DomainKeys is to define a simple, cheap, and
   "sufficiently effective" mechanism by which domain owners can control
   who has authority to send email using their domain.  To this end, the
   designers of DomainKeys set out to build a framework that:

      o  is transparent and compatible with the existing email
         infrastructure

      o  requires no new infrastructure

      o  can be implemented independently of clients in order to reduce
         deployment time

      o  does not require the use of a central certificate authority
         that might impose fees for certificates or introduce delays to
         deployment

      o  can be deployed incrementally

   While we believe that DomainKeys meets these criteria, it is by no
   means a perfect solution.  The current Internet imposes considerable
   compromises on any similar scheme, and readers should be careful not
   to misinterpret the information provided in this document to imply
   that DomainKeys makes stronger credibility statements than it is able
   to do.

1.8.  Benefits of DomainKeys

   As the reader will discover, DomainKeys is solely an authentication
   system.  It is not a magic bullet for spam, nor is it an
   authorization system, a reputation system, a certification system, or
   a trust system.

   However, a strong authentication system such as DomainKeys creates an
   unimpeachable framework within which comprehensive authorization
   systems, reputations systems, and their ilk can be developed.










Delany                          Historic                        [Page 6]

RFC 4870                       DomainKeys                       May 2007


1.9.  Definitions

   With reference to the following sample email:

   Line   Data
   Number Bytes               Content
   ----   --- --------------------------------------------
     01    46 From: "Joe SixPack" 
     02    40 To: "Suzie Q" 
     03    25 Subject: Is dinner ready?
     04    43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
     05    40 Comment: This comment has a continuation
     06    51   because this line begins with folding white space
     07    60 Message-ID: <20030712040037.46341@football.example.com>
     08    00
     09    03 Hi.
     10    00
     11    37 We lost the game. Are you hungry yet?
     12    00
     13    04 Joe.
     14    00
     15    00

   Line 01 is the first line of the email and the first line of the
         headers.

   Lines 05 and 06 constitute the "Comment:" header.

   Line 06 is a continuation header line.

   Line 07 is the last line of the headers.

   Line 08 is the empty line that separates the header from the body.

   Line 09 is the first line of the body.

   Lines 10, 12, 14, and 15 are empty lines.

   Line 13 is the last non-empty line of the email.

   Line 15 is the last line of the body and the last line of the email.

   Lines 01 to 15 constitute the complete email.

   Line 01 is earlier than line 02, and line 02 is later than line 01.






Delany                          Historic                        [Page 7]

RFC 4870                       DomainKeys                       May 2007


1.10.  Requirements Notation

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
   NOT", and "MAY" appear capitalized, they are being used to indicate
   particular requirements of this specification.  A discussion of the
   meanings of these terms appears in [RFC2119].

2.  DomainKeys Overview

   Under DomainKeys, a domain owner generates one or more private/public
   key pairs that will be used to sign messages originating from that
   domain.  The domain owner places the public key in his domain
   namespace (i.e., in a DNS record associated with that domain), and
   makes the private key available to the outbound email system.  When
   an email is submitted by an authorized user of that domain, the email
   system uses the private key to digitally sign the email associated
   with the sending domain.  The signature is added as a header to the
   email, and the message is transferred to its recipients in the usual
   way.

   When a message is received with a DomainKey signature header, the
   receiving system can verify the signature as follows:

      1. Extract the signature and claimed sending domain from the
         email.

      2. Fetch the public key from the claimed sending domain namespace.

      3. Use public key to determine whether the signature of the email
         has been generated with the corresponding private key, and thus
         whether the email was sent with the authority of the claimed
         sending domain.

   In the event that an email arrives without a signature or when the
   signature verification fails, the receiving system retrieves the
   policy of the claimed sending domain to ascertain the preferred
   disposition of such email.

   Armed with this information, the recipient system can apply local
   policy based on the results of the signature test.

3.  DomainKeys Detailed View

   This section discusses the specifics of DomainKeys that are needed to
   create interoperable implementations.  This section answers the
   following questions:




Delany                          Historic                        [Page 8]

RFC 4870                       DomainKeys                       May 2007


      Given an email, how is the sending domain determined?

      How is the public key retrieved for a sending domain?

      As email transits the email system, it can potentially go through
      a number of changes.  Which parts of the email are included in the
      signature and how are they protected from such transformations?

      How is the signature represented in the email?

      If a signature is not present, or a verification fails, how does
      the recipient determine the policy intent of the sending domain?

      Finally, on verifying the authenticity of an email, how is that
      result conveyed to participating MUAs?

   While there are many alternative design choices, most lead to
   comparable functionality.  The overriding selection criteria used to
   choose among the alternatives are as follows:

      o  use deployed technology whenever possible

      o  prefer ease of implementation

      o  avoid trading risk for excessive flexibility or
         interoperability

      o  include basic flexibility

   Adherence to these criteria implies that some existing email
   implementations will require changes to participate in DomainKeys.
   Ultimately, some hard choices need to be made regarding which
   requirements are more important.

3.1.  Determining the Sending Address of an Email

   The goal of DomainKeys is to give the recipient confidence that the
   email originated from the claimed sender.  As with much of Internet
   email, agreement over what constitutes the "sender" is no easy
   matter.  Forwarding systems and mailing lists add serious
   complications to an overtly simple question.  From the point of view
   of the recipient, the authenticity claim should be directed at the
   domain most visible to the recipient.

   In the first instance, the most visible address is clearly the RFC
   2822 "From:" address [RFC2822].  Therefore, a conforming email MUST
   contain a single "From:" header from which an email address with a
   domain name can be extracted.



Delany                          Historic                        [Page 9]

RFC 4870                       DomainKeys                       May 2007


   A conforming email MAY contain a single RFC 2822 "Sender:" header
   from which an email address with a domain name can be extracted.

   If the email has a valid "From:" and a valid "Sender:" header, then
   the signer MUST use the sending address in the "Sender:" header.

   If the email has a valid "From:" and no "Sender:" header, then the
   signer MUST use the first sending address in the "From:" header.

   In all other cases, a signer MUST NOT sign the email.  Implementors
   should note that an email with a "Sender:" header and no "From:"
   header MUST NOT be signed.

   The domain name in the sending address constitutes the "sending
   domain".

3.2.  Retrieving the Public Key Given the Sending Domain

   To avoid namespace conflicts, it is proposed that the DNS namespace
   "_domainkey." be reserved within the sending domain for storing
   public keys, e.g., if the sending domain is example.net, then the
   public keys for that domain are stored in the _domainkey.example.net
   namespace.

3.2.1.  Introducing "selectors"

   To support multiple concurrent public keys per sending domain, the
   DNS namespace is further subdivided with "selectors".  Selectors are
   arbitrary names below the "_domainkey." namespace.  A selector value
   and length MUST be legal in the DNS namespace and in email headers
   with the additional provision that they cannot contain a semicolon.

   Examples of namespaces using selectors are as follows:

      "coolumbeach._domainkey.example.net"
      "sebastopol._domainkey.example.net"
      "reykjavik._domainkey.example.net"
      "default._domainkey.example.net"

   and

      "2005.pao._domainkey.example.net"
      "2005.sql._domainkey.example.net"
      "2005.rhv._domainkey.example.net"

   Periods are allowed in selectors and are to be treated as component
   separators.  In the case of DNS queries, that means the period
   defines subdomain boundaries.



Delany                          Historic                       [Page 10]

RFC 4870                       DomainKeys                       May 2007


   The number of public keys and corresponding selectors for each domain
   is determined by the domain owner.  Many domain owners will be
   satisfied with just one selector, whereas administratively
   distributed organizations may choose to manage disparate selectors
   and key pairs in different regions, or on different email servers.

   Beyond administrative convenience, selectors make it possible to
   seamlessly replace public keys on a routine basis.  If a domain
   wishes to change from using a public key associated with selector
   "2005" to a public key associated with selector "2006", it merely
   makes sure that both public keys are advertised in the DNS
   concurrently for the transition period during which email may be in
   transit prior to verification.  At the start of the transition
   period, the outbound email servers are configured to sign with the
   "2006" private key.  At the end of the transition period, the "2005"
   public key is removed from the DNS.

   While some domains may wish to make selector values well known,
   others will want to take care not to allocate selector names in a way
   that allows harvesting of data by outside parties.  For example, if
   per-user keys are issued, the domain owner will need to make the
   decision as to whether to make this selector associated directly with
   the user name or make it some unassociated random value, such as the
   fingerprint of the public key.

3.2.2.  Public Key Signing and Verification Algorithm

   The default signature is an RSA signed SHA1 digest of the complete
   email.

   For ease of explanation, the openssl command is used throughout this
   document to describe the mechanism by which keys and signatures are
   managed.

   One way to generate a 768-bit private key suitable for DomainKeys is
   to use openssl like this:

   $ openssl genrsa -out rsa.private 768













Delany                          Historic                       [Page 11]

RFC 4870                       DomainKeys                       May 2007


   which results in the file rsa.private containing the key information
   similar to this:

   -----BEGIN RSA PRIVATE KEY-----
   MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
   ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
   AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
   +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
   Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
   3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
   ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
   FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
   weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
   6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
   -----END RSA PRIVATE KEY-----

   Once a private key has been generated, the openssl command can be
   used to sign an appropriately prepared email, like this:

   $ openssl dgst -sign rsa.private -sha1 
   To: "Suzie Q" 
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

4.2.  The Email Is Signed

   This email is signed by the football.example.com outbound email
   server and now looks like this:

   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
     c=simple; q=dns;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
       VoG4ZHRNiYzR;
   Received: from dsl-10.2.3.4.football.example.com  [10.2.3.4]
        by submitserver.football.example.com with SUBMISSION;
        Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: "Joe SixPack" 
   To: "Suzie Q" 
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

   The signing email server requires access to the private key
   associated with the "brisbane" selector to generate this signature.
   Distribution and management of private keys are outside the scope of
   this document.



Delany                          Historic                       [Page 29]

RFC 4870                       DomainKeys                       May 2007


4.3.  The Email Signature Is Verified

   The signature is normally verified by an inbound SMTP server or
   possibly the final delivery agent.  However, intervening MTAs can
   also perform this verification if they choose to do so.

   The verification process uses the domain "football.example.com"
   extracted from the "From:" header and the selector "brisbane" from
   the "DomainKey-Signature:" header to form the DNS TXT query for:

      brisbane._domainkey.football.example.com

   Since there is no "h" tag in the "DomainKey-Signature:" header,
   signature verification starts with the line following the
   "DomainKey-Signature:" line.  The email is canonically prepared for
   verifying with the "simple" method.

   The result of the query and subsequent verification of the signature
   is stored in the "DomainKey-Status:" header line.  After successful
   verification, the email looks like this:

   DomainKey-Status: good
    from=joe@football.example.com; domainkeys=pass
   Received: from mout23.brisbane.football.example.com (192.168.1.1)
             by shopping.example.net with SMTP;
             Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
    c=simple; q=dns;
    b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
      VoG4ZHRNiYzR;
   Received: from dsl-10.2.3.4.network.example.com  [10.2.3.4]
        by submitserver.example.com with SUBMISSION;
        Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: "Joe SixPack" 
   To: "Suzie Q" 
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.







Delany                          Historic                       [Page 30]

RFC 4870                       DomainKeys                       May 2007


5.  Association with a Certificate Authority

   A fundamental aspect of DomainKeys is that public keys are generated
   and advertised by each domain at no additional cost.  This
   accessibility markedly differs from traditional Public Key
   Infrastructures where there is typically a Certificate Authority (CA)
   who validates an applicant and issues a signed certificate --
   containing their public key -- often for a recurring fee.

   While CAs do impose costs, they also have the potential to provide
   additional value as part of their certification process.  Consider
   financial institutions, public utilities, law enforcement agencies,
   and the like.  In many cases, such entities justifiably need to
   discriminate themselves above and beyond the authentication that
   DomainKeys offers.

   Creating a link between DomainKeys and CA-issued certificates has the
   potential to access additional authentication mechanisms that are
   more authoritative than domain-owner-issued authentication.  It is
   well beyond the scope of this specification to describe such
   authorities apart from defining how the linkage could be achieved
   with the "DomainKey-X509:" header.

5.1.  The "DomainKey-X509:" Header

   The "DomainKey-X509:" header provides a link between the public key
   used to sign the email and the certificate issued by a CA.

   The exact content, syntax, and semantics of this header are yet to be
   resolved.  One possibility is that this header contains an encoding
   of the certificate issued by a CA.  Another possibility is that this
   header contains a URL that points to a certificate issued by a CA.

   In either case, this header can only be consulted if the signature
   verifies and MUST be part of the content signed by the corresponding
   "DomainKey-Signature:" header.  Furthermore, it is likely that MUAs
   rather than MTAs will confirm that the link to the CA-issued
   certificate is valid.  In part, this is because many MUAs already
   have built-in capabilities as a consequence of Secure/Multipurpose
   Internet Mail Extensions (S/MIME) [SMIME] and Secure Socket Layer
   (SSL) [SSL] support.

   The proof of linkage is made by testing that the public key in the
   certificate matches the public key used to sign the email.







Delany                          Historic                       [Page 31]

RFC 4870                       DomainKeys                       May 2007


   An example of an email containing the "DomainKey-X509:" header is:

      DomainKey-Signature: a=rsa-sha1; s=statements;
        d=largebank.example.com; c=simple; q=dns;
        b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
          VoG4ZHRNiYzR;
      DomainKey-X509: https://ca.example.net/largebank.example.com
      From: "Large Bank" 
      To: "Suzie Q" 
      Subject: Statement for Account: 1234-5678
      ...

   The format of the retrieved value from the URL is not yet defined,
   nor is the determination of valid CAs.

   The whole matter of linkage to CA-issued certificates is one aspect
   of DomainKeys that needs to be resolved with relevant CA's and
   certificate-issuing entities.  The primary point is that a link is
   possible to a higher authority.

6.  Topics for Discussion

6.1.  The Benefits of Selectors

   Selectors are at the heart of the flexibility of DomainKeys.  A
   domain administrator is free to use a single DomainKey for all
   outbound mail.  Alternatively, the domain administrator may use many
   DomainKeys differentiated by selector and assign each key to
   different servers.

   For example, a large outbound email farm might have a unique
   DomainKey for each server, and thus their DNS will advertise
   potentially hundreds of keys via their unique selectors.

   Another example is a corporate email administrator who might generate
   a separate DomainKey for each regional office email server.

   In essence, selectors allow a domain owner to distribute authority to
   send on behalf of that domain.  Combined with the ability to revoke
   by removal or Time to Live (TTL) expiration, a domain owner has
   coarse-grained control over the duration of the distributed
   authority.

   Selectors are particularly useful for domain owners who want to
   contract a third-party mailing system to send a particular set of
   mail.  The domain owner can generate a special key pair and selector
   just for this mail-out.  The domain owner has to provide the private
   key and selector to the third party for the life of the mail-out.



Delany                          Historic                       [Page 32]

RFC 4870                       DomainKeys                       May 2007


   However, as soon as the mail-out is completely delivered, the domain
   owner can revoke the public key by the simple expedient of removing
   the entry from the DNS.

6.2.  Canonicalization of Email

   It is an unfortunate fact that some email software routinely (and
   often unnecessarily) transforms email as it transits through the
   network.  Such transformations conflict with the fundamental purpose
   of cryptographic signatures - to detect modifications.

   While two canonicalization algorithms are defined in this
   specification, the primary goal of "nofws" is to provide a transition
   path to "simple".  With a mixture of "simple" and "nofws" email, a
   receiver can determine which systems are modifying email in ways that
   cause the signature to fail and thus provide feedback to the
   modifying system.

6.3.  Mailing Lists

   Integrating existing Mailing List Managers (MLMs) into the DomainKeys
   authentication system is a complicated area, as the behavior of MLMs
   is highly variable.  Essentially, there are two types of MLMs under
   consideration: those that modify email to such an extent that
   verification of the original content is not possible, and those that
   make minimal or no modifications to an email.

   MLMs that modify email in a way that causes verification to fail MUST
   prepend a "Sender:" header and SHOULD prepend a "List-ID:"  header
   prior to signing for distribution to list recipients.

   A participating SUBMISSION server can deduce the need to re-sign such
   an email by the presence of a "Sender:" or "List-ID:" header from an
   authorized submission.

   MLMs that do not modify email in a way that causes verification to
   fail MAY perform the same actions as a modifying MLM.

6.4.  Roving Users

   One scenario that presents a particular problem with any form of
   email authentication, including DomainKeys, is the roving user: a
   user who is obliged to use a third-party SUBMISSION service when
   unable to connect to the user's own SUBMISSION service.  The classic
   example cited is a traveling salesperson being redirected to a hotel
   email server to send email.





Delany                          Historic                       [Page 33]

RFC 4870                       DomainKeys                       May 2007


   As far as DomainKeys is concerned, email of this nature clearly
   originates from an email server that does not have authority to send
   on behalf of the domain of the salesperson and is therefore
   indistinguishable from a forgery.  While DomainKeys does not
   prescribe any specific action for such email, it is likely that over
   time, such email will be treated as second-class email.

   The typical solution offered to roving users is to submit email via
   an authorized server for their domain -- perhaps via a Virtual
   Private Network (VPN) or a web interface or even SMTP AUTH back to a
   SUBMISSION server.

   While these are perfectly acceptable solutions for many, they are not
   necessarily solutions that are available or possible for all such
   users.

   One possible way to address the needs of this contingent of
   potentially disenfranchised users is for the domain to issue per-user
   DomainKeys.  Per-user DomainKeys are identified by a non-empty "g"
   tag value in the corresponding DNS record.

7.  Security Considerations

7.1.  DNS

   DomainKeys is primarily a security mechanism.  Its core purpose is to
   make claims about email authentication in a credible way.  However,
   DomainKeys, like virtually all Internet applications, relies on the
   DNS, which has well-known security flaws [RFC3833].

7.1.1.  The DNS Is Not Currently Secure

   While the DNS is currently insecure, it is expected that the security
   problems should and will be solved by DNS Security (DNSSEC) [DNSSEC],
   and all users of the DNS will reap the benefit of that work.

   Secondly, the types of DNS attacks relevant to DomainKeys are very
   costly and are far less rewarding than DNS attacks on other Internet
   applications.

   To systematically thwart the intent of DomainKeys, an attacker must
   conduct a very costly and very extensive attack on many parts of the
   DNS over an extended period.  No one knows for sure how attackers
   will respond; however, the cost/benefit of conducting prolonged DNS
   attacks of this nature is expected to be uneconomical.

   Finally, DomainKeys is only intended as a "sufficient" method of
   proving authenticity.  It is not intended to provide strong



Delany                          Historic                       [Page 34]

RFC 4870                       DomainKeys                       May 2007


   cryptographic proof about authorship or contents.  Other technologies
   such as GnuPG and S/MIME address those requirements.

7.1.2.  DomainKeys Creates Additional DNS Load

   A second security issue related to the DNS revolves around the
   increased DNS traffic as a consequence of fetching selector-based
   data, as well as fetching sending domain policy.  Widespread
   deployment of DomainKeys will result in a significant increase in DNS
   queries to the claimed sending domain.  In the case of forgeries on a
   large scale, DNS servers could see a substantial increase in queries.

7.2.  Key Management

   All public key systems require management of key pairs.  Private keys
   in particular need to be securely distributed to each signing mail
   server and protected on those servers.  For those familiar with SSL,
   the key management issues are similar to those of managing SSL
   certificates.  Poor key management may result in unauthorized access
   to private keys, which in essence gives unauthorized access to your
   identity.

7.3.  Implementation Risks

   It is well recognized in cryptographic circles that many security
   failures are caused by poor implementations rather than poor
   algorithms.  For example, early SSL implementations were vulnerable
   because the implementors used predictable "random numbers".

   While some MTA software already supports various cryptographic
   techniques, such as TLS, many do not.  This proposal introduces
   cryptographic requirements into MTA software that implies a much
   higher duty of care to manage the increased risk.

   There are numerous articles, books, courses, and consultants that
   help programming security applications.  Potential implementors are
   strongly encouraged to avail themselves of all possible resources to
   ensure secure implementations.

7.4.  Privacy Assumptions with Forwarding Addresses

   Some people believe that they can achieve anonymity by using an email
   forwarding service.  While this has never been particularly true, as
   bounces, over-quota messages, vacation messages, and web bugs all
   conspire to expose IP addresses and domain names associated with the
   delivery path, the DNS queries that are required to verify DomainKeys
   signature can provide additional information to the sender.




Delany                          Historic                       [Page 35]

RFC 4870                       DomainKeys                       May 2007


   In particular, as mail is forwarded through the mail network, the DNS
   queries for the selector will typically identify the DNS cache used
   by the forwarding and delivery MTAs.

7.5.  Cryptographic Processing Is Computationally Intensive

   Verifying a signature is computationally significant.  Early
   indications are that a typical mail server can expect to increase CPU
   demands by 8-15 percent.  While this increased demand is modest
   compared to other common mail processing costs -- such as Bayesian
   filtering -- any increase in resource requirements can make a
   denial-of-service attack more effective against a mail system.

   A constraining factor of such attacks is that the net computational
   cost of verifying is bounded by the maximum key size allowed by this
   specification and is essentially linear to the rate at which mail is
   accepted by the verifying system.  Consequently, the additional
   computational cost may augment a denial-of-service attack, but it
   does not add a non-linear component to such attacks.

8.  The Trial

   The DomainKeys protocol was deployed as a trial to better understand
   the implications of deploying wide-scale cryptographic email
   authentication.

   Open Source implementations were made available at various places,
   particularly Source Forge [SOURCEFORGE], which includes links to
   numerous implementations, both Open Source and commercial.

8.1.  Goals

   The primary goals of the trial were to:

      o  understand the operational implications of running a DNS-based
         public key system for email

      o  measure the effectiveness of the canonicalization algorithms

      o  experiment with possible per-user key deployment models

      o  fully define the semantics of the "DomainKey-X509:" header









Delany                          Historic                       [Page 36]

RFC 4870                       DomainKeys                       May 2007


8.2.  Results of Trial

   The DomainKeys trial ran for approximately 2 years, in which time
   numerous large ISPs and many thousands of smaller domains
   participated in signing or verifying with DomainKeys.  The low order
   numbers are that at least one billion DomainKey signed emails transit
   the Internet each day between some 12,000 participating domains.

   The operational and development experience of that trial was applied
   to DKIM.

9.  Note to Implementors Regarding TXT Records

   The DNS is very flexible in that it is possible to have multiple TXT
   records for a single name and for those TXT records to contain
   multiple strings.

   In all cases, implementors of DomainKeys should expect a single TXT
   record for any particular name.  If multiple TXT records are
   returned, the implementation is free to pick any single TXT record as
   the authoritative data.  In other words, if a name server returns
   different TXT records for the same name, it can expect unpredictable
   results.

   Within a single TXT record, implementors should concatenate multiple
   strings in the order presented and ignore string boundaries.  Note
   that a number of popular DNS command-line tools render multiple
   strings as separately quoted strings, which can be misleading to a
   novice implementor.

10.  References

10.1.  Normative References

   [BASE64]      Josefsson, S., "The Base16, Base32, and Base64 Data
                 Encodings", RFC 4648, October 2006.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [PEM]         Linn, J., "Privacy Enhancement for Internet Electronic
                 Mail: Part I: Message Encryption and Authentication
                 Procedures", RFC 1421 February, 1993.








Delany                          Historic                       [Page 37]

RFC 4870                       DomainKeys                       May 2007


10.2.  Informative References

   [DKIM]        Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
                 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
                 Signatures", RFC 4871, May 2007.

   [DNSSEC]      http://www.ietf.org/html.charters/dnsext-charter.html

   [OPENSSL]     http://www.openssl.org

   [RFC2822]     Resnick, P., Editor, "Internet Message Format", RFC
                               2822, April 2001.

   [RFC3833]     Atkins, D. and R. Austein, "Threat Analysis of the
                 Domain Name System (DNS)", RFC 3833, August 2004.

   [SMIME]       Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                 Extensions (S/MIME) Version 3.1 Message Specification",
                 RFC 3851, July 2004.

   [SOURCEFORGE] http://domainkeys.sourceforge.net

   [SSL]         http://wp.netscape.com/security/techbriefs/ssl.html




























Delany                          Historic                       [Page 38]

RFC 4870                       DomainKeys                       May 2007


Appendix A - Syntax Rules for the Tag=Value Format

   A simple tag=value syntax is used to encode data in the response
   values for DNS queries as well as headers embedded in emails.  This
   section summarized the syntactic rules for this encoding:

      o  A tag=value pair consists of three tokens, a "tag", the "="
         character, and the "value"

      o  A tag MUST be one character long and MUST be a lowercase
         alphabetic character

      o  Duplicate tags are not allowed

      o  A value MUST only consist of characters that are valid in RFC
         2822 headers and DNS TXT records and are within the ASCII range
         of characters from SPACE (0x20) to TILDE (0x7E) inclusive.
         Values MUST NOT contain a semicolon but they may contain "="
         characters.

      o  A tag=value pair MUST be terminated by a semicolon or the end
         of the data

      o  Values MUST be processed as case sensitive unless the specific
         tag description of semantics imply case insensitivity.

      o  Values MAY be zero bytes long

      o  Whitespace MAY surround any of the tokens; however, whitespace
         within a value MUST be retained unless explicitly excluded by
         the specific tag description.  Currently, the only tags that
         specifically ignore embedded whitespace are the "b" and "h"
         tags in the "DomainKey-Signature:" header.

      o  Tag=value pairs that represent the default value MAY be
         included to aid legibility.

      o  Unrecognized tags MUST be ignored













Delany                          Historic                       [Page 39]

RFC 4870                       DomainKeys                       May 2007


Acknowledgments

   The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki,
   Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy,
   Jutta Degener, Timothy Der, Jim Fenton, Duncan Findlay, Phillip
   Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David
   Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer
   Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte
   S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their
   valuable suggestions and constructive criticism.

Author's Address

   Mark Delany
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA 95087
   USA

   EMail: markd+domainkeys@yahoo-inc.com































Delany                          Historic                       [Page 40]

RFC 4870                       DomainKeys                       May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Delany                          Historic                       [Page 41]


 

RFC, FYI, BCP