









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" <joe@football.example.com>

     02    40 To: "Suzie Q" <suzie@shopping.example.net>

     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 <input.file



   which results in signature data similar to this when represented in

   Base64 [BASE64] format:



   aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz

   msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl



   How this signature is added to the email is discussed later in this

   document.



   To extract the public key component from the private key, use openssl

   like this:



   $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM



   which results in the file rsa.public containing the key information

   similar to this:



   -----BEGIN PUBLIC KEY-----

   MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l

   MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E

   XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB

   -----END PUBLIC KEY-----



   This public key data is placed in the DNS.













Delany                          Historic                       [Page 12]



RFC 4870                       DomainKeys                       May 2007





   With the signature, canonical email contents and public key, a

   verifying system can test the validity of the signature.  The openssl

   invocation to verify a signature looks like this:



 $ openssl dgst -verify rsa.public -sha1 -signature sig.file <input.file



3.2.3.  Public key Representation in the DNS



   There is currently no standard method defined for storing public keys

   in the DNS.  As an interim measure, the public key is stored as a TXT

   record derived from a Privacy-Enhanced Mail (PEM) format [PEM], that

   is, as a Base64 representation of a DER encoded key.  Here is an

   example of a 768-bit RSA key in PEM form:



   -----BEGIN PUBLIC KEY-----

   MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l

   MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E

   XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB

   -----END PUBLIC KEY-----



   To save scarce DNS packet space and aid extensibility, the PEM

   wrapping MUST be removed and the remaining public key data along with

   other attributes relevant to DomainKeys functionality are stored as

   tag=value pairs separated by semicolons, for example, as in the

   following:



   brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"



   Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048

   bits.  Signers MUST support at least one of the verifier supported

   key sizes.



   The current valid tags are as follows:



      g = granularity of the key.  If present with a non-zero length

          value, this value MUST exactly match the local part of the

          sending address.  This tag is optional.



          The intent of this tag is to constrain which sending address

          can legitimately use this selector.  An email with a sending

          address that does not match the value of this tag constitutes

          a failed verification.



      k = key type (rsa is the default).  Signers and verifiers MUST

          support the 'rsa' key type.  This tag is optional.













Delany                          Historic                       [Page 13]



RFC 4870                       DomainKeys                       May 2007





      n = Notes that may be of interest to a human.  No interpretation

          is made by any program.  This tag is optional.



      p = public key data, encoded as a Base64 string.  An empty value

          means that this public key has been revoked.  This tag MUST be

          present.



      t = a set of flags that define boolean attributes.  Valid

          attributes are as follows:



          y = testing mode.  This domain is testing DomainKeys and

              unverified email MUST NOT be treated differently from

              verified email.  Recipient systems MAY wish to track

              testing mode results to assist the sender.



          This tag is optional.



   (Syntax rules for the tag=value format are discussed in Appendix A.)



   Keeping the size of the TXT record to a minimum is important as some

   implementations of content and caching DNS servers are reported to

   have problems supporting large TXT records.  In the example above,

   the encoding generates a 182-byte TXT record.  That this encoding is

   less than 512 bytes is of particular significance as it fits within a

   single UDP response packet.  With careful selection of query values,

   a TXT record can accommodate a 2048 bit key.



   For the same size restriction reason, the "n" tag SHOULD be used

   sparingly.  The most likely use of this tag is to convey a reason why

   a public key might have been revoked.  In this case, set the "n" tag

   to the explanation and remove the public key value from the "p" tag.



3.2.4.  Key Sizes



   Selecting appropriate key sizes is a trade-off between cost,

   performance, and risk.  This specification does not define either

   minimum or maximum key sizes -- that decision is a matter for each

   domain owner.



   Factors that should influence this decision include the following:



      o  the practical constraint that a 2048-bit key is the largest key

         that fits within a 512-byte DNS UDP response packet



      o  larger keys impose higher CPU costs to verify and sign email



      o  keys can be replaced on a regular basis; thus, their lifetime

         can be relatively short







Delany                          Historic                       [Page 14]



RFC 4870                       DomainKeys                       May 2007





      o  the security goals of this specification are modest compared to

         typical goals of public key systems



   In general, it is expected that most domain owners will use keys that

   are no larger than 1024 bits.



3.3.  Storing the Signature in the Email Header



   The signature of the email is stored in the "DomainKey-Signature:"

   header.  This header contains all of the signature and key-fetching

   data.



   When generating the signed email, the "DomainKey-Signature:" header

   MUST precede the original email headers presented to the signature

   algorithm.



   The "DomainKey-Signature:" header is not included in the signature

   calculation.



   For extensibility, the "DomainKey-Signature:" header contains

   tag=value pairs separated by semicolons, for example, as in the

   following:



   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;

     q=dns; c=simple



   The current valid tags are as follows:



      a = The algorithm used to generate the signature.  The default is

          "rsa-sha1", an RSA signed SHA1 digest.  Signers and verifiers

          MUST support "rsa-sha1".



      b = The signature data, encoded as a Base64 string.  This tag MUST

          be present.



          Whitespace is ignored in this value and MUST be removed when

          reassembling the original signature.  This is another way of

          saying that the signing process can safely insert folding

          whitespace in this value to conform to line-length limits.



      c = Canonicalization algorithm.  The method by which the headers

          and content are prepared for presentation to the signing

          algorithm.  This tag MUST be present.  Verifiers MUST support

          "simple" and "nofws".  Signers MUST support at least one of

          the verifier-supported algorithms.













Delany                          Historic                       [Page 15]



RFC 4870                       DomainKeys                       May 2007





      d = The domain name of the signing domain.  This tag MUST be

          present.  In conjunction with the selector tag, this domain

          forms the basis of the public key query.  The value in this

          tag MUST match the domain of the sending email address or MUST

          be one of the parent domains of the sending email address.

          Domain name comparison is case insensitive.



             The matching process for this tag is called subdomain

             matching, as the sending email address must be the domain

             or subdomain of the value.



      h = A colon-separated list of header field names that identify the

          headers presented to the signing algorithm.  If present, the

          value MUST contain the complete list of headers in the order

          presented to the signing algorithm.



          If present, this tag MUST include the header that was used to

          identify the sending domain, i.e., the "From:" or "Sender:"

          header; thus, this tag can never contain an empty value.



          If this tag is not present, all headers subsequent to the

          signature header are included in the order found in the email.



          A verifier MUST support this tag.  A signer MAY support this

          tag.  If a signer generates this tag, it MUST include all

          email headers in the original email, as a verifier MAY remove

          or render suspicious, lines that are not included in the

          signature.



          In the presence of duplicate headers, a signer may include

          duplicate entries in the list of headers in this tag.  If a

          header is included in this list, a verifier must include all

          occurrences of that header, subsequent to the "DomainKey-

          Signature:" header in the verification.



          If a header identified in this list is not found after the

          "DomainKey-Signature:" header in the verification process, a

          verifier may "look" for a matching header prior to the

          "DomainKey-Signature:" header; however, signers should not

          rely on this as early experience suggests that most verifiers

          do not try to "look" back before the "DomainKey-Signature:"

          header.



          Whitespace is ignored in this value and header comparisons are

          case insensitive.













Delany                          Historic                       [Page 16]



RFC 4870                       DomainKeys                       May 2007





      q = The query method used to retrieve the public key.  This tag

          MUST be present.  Currently, the only valid value is "dns",

          which defines the DNS lookup algorithm described in this

          document.  Verifiers and signers MUST support "dns".



      s = The selector used to form the query for the public key.  This

          tag MUST be present.  In the DNS query type, this value is

          prepended to the "_domainkey." namespace of the sending

          domain.



   (Syntax rules for the tag=value format are discussed in Appendix A.)



   Here is an example of a signature header spread across multiple

   continuation lines:



      DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;

       c=simple; q=dns;

       b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ

         VoG4ZHRNiYzR;



   Extreme care must be taken to ensure that any new tags added to this

   header are defined and used solely for the purpose of fetching and

   verifying the signature.  Any semantics beyond verification cannot be

   trusted, as this header is not protected by the signature.



   If additional semantics not pertaining directly to signature

   verification are required, they must only be added as subsequent

   headers protected by the signature.  Semantic additions might include

   audit information describing the initial submission.



3.4.  Preparation of Email for Transit and Signing



   The fundamental purpose of a cryptographic signature is to ensure

   that the signed content matches the contents presented for

   verification.  However, unlike just about every other Internet

   protocol, the email content is routinely modified as it enters and

   transits the email system.



   Fortunately most of the modifications typically made to email can be

   predicted and consequently accounted for when signing and verifying.



   To maximize the chance of a successful verification, submitted email

   should be prepared for transport prior to signing, and the data

   presented to the signing algorithm is canonicalized to exclude the

   most common and minor changes made to email.













Delany                          Historic                       [Page 17]



RFC 4870                       DomainKeys                       May 2007





3.4.1.  Preparation for Transit



   The SMTP protocol defines a number of potential limitations to email

   transport, particularly pertaining to line lengths and 8-bit content.



   While the editor has observed that most modern SMTP implementations

   accept 8-bit email and long lines, some implementations still do not.

   Consequently, a DomainKeys implementation SHOULD prepare an email to

   be suitable for the lowest common denominator of SMTP prior to

   presenting the email for signing.



3.4.2.  Canonicalization for Signing



   DomainKeys is initially expected to be deployed at, or close to, the

   email borders of an organization rather than in MUAs or SUBMISSION

   servers.  In other words, the signing and verifying algorithms

   normally apply after an email has been packaged, transmogrified, and

   generally prepared for transmission across the Internet via SMTP and,

   thus the likelihood of the email being subsequently modified is

   reduced.



   Nonetheless, empirical evidence suggests that some mail servers and

   relay systems modify email in transit, potentially invalidating a

   signature.



   There are two competing perspectives on such modifications.  For most

   senders, mild modification of email is immaterial to the

   authentication status of the email.  For such senders, a

   canonicalization algorithm that survives modest in-transit

   modification is preferred.



   For other senders however, any modification of the email - however

   minor -- results in a desire for the authentication to fail.  In

   other words, such senders do not want a modified email to be seen as

   being authorized by them.  These senders prefer a canonicalization

   algorithm that does not tolerate in-transit modification of the

   signed email.



   To satisfy both requirements, two canonicalization algorithms are

   defined.  A "simple" algorithm that tolerates almost no modification

   and a "nofws" algorithm that tolerates common modifications as

   whitespace replacement and header line rewrapping.



   A sender may choose either algorithm when signing an email.  A

   verifier MUST be able to process email using either algorithm.



   Either algorithm can be used in conjunction with the "h" tag in the

   "DomainKey-Signature:" header.







Delany                          Historic                       [Page 18]



RFC 4870                       DomainKeys                       May 2007





   Canonicalization simply prepares the email for the signing or

   verification algorithm.  It does not change the transmitted data in

   any way.



3.4.2.1.  The "simple" Canonicalization Algorithm



   o  Each line of the email is presented to the signing algorithm in

      the order it occurs in the complete email, from the first line of

      the headers to the last line of the body.



   o  If the "h" tag is used, only those header lines (and their

      continuation lines if any) added to the "h" tag list are included.



   o  The "h" tag only constrains header lines.  It has no bearing on

      body lines, which are always included.



   o  Remove any local line terminator.



   o  Append CRLF to the resulting line.



   o  All trailing empty lines are ignored.  An empty line is a line of

      zero length after removal of the local line terminator.



      If the body consists entirely of empty lines, then the header/body

      line is similarly ignored.



3.4.2.2.  The "nofws" Canonicalization Algorithm



   The "No Folding Whitespace" algorithm (nofws) is more complicated

   than the "simple" algorithm for two reasons; folding whitespace is

   removed from all lines and header continuation lines are unwrapped.



      o  Each line of the email is presented to the signing algorithm in

         the order it occurs in the complete email, from the first line

         of the headers to the last line of the body.



      o  Header continuation lines are unwrapped so that header lines

         are processed as a single line.



      o  If the "h" tag is used, only those header lines (and their

         continuation lines if any) added to the "h" tag list are

         included.



      o  The "h" tag only constrains header lines.  It has no bearing on

         body lines, which are always included.













Delany                          Historic                       [Page 19]



RFC 4870                       DomainKeys                       May 2007





      o  For each line in the email, remove all folding whitespace

         characters.  Folding whitespace is defined in RFC 2822 as being

         the decimal ASCII values 9 (HTAB), 10 (NL), 13 (CR), and 32

         (SP).



      o  Append CRLF to the resulting line.



      o  Trailing empty lines are ignored.  An empty line is a line of

         zero length after removal of the local line terminator.  Note

         that the test for an empty line occurs after removing all

         folding whitespace characters.



         If the body consists entirely of empty lines, then the

         header/body line is similarly ignored.



3.5.  The Signing Process



   The previous sections defined the various components and mechanisms

   needed to sign an email.  This section brings those together to

   define the complete process of signing an email.



   A signer MUST only sign email from submissions that are authorized to

   use the sending address.



   Once authorization of the submission has been determined, the signing

   process consists of the following steps:



      o  identifying the sending domain



      o  determining if an email should be signed



      o  selecting a private key and corresponding selector information



      o  calculating the signature value



      o  prepending the "DomainKey-Signature:" header



   If an email cannot be signed for some reason, it is a local policy

   decision as to what to do with that email.



3.5.1.  Identifying the Sending Domain



   The sending domain is determined by finding the email address in the

   "Sender:" header, or, if the "Sender:" header is not present, the

   first email address of the "From:" header is used to determine the

   sending domain.











Delany                          Historic                       [Page 20]



RFC 4870                       DomainKeys                       May 2007





   If the email has an invalid "From:" or an invalid "Sender:" header,

   it MUST NOT be signed.



   If the signer adds the "h" tag to the "DomainKey-Signature:" header,

   that tag MUST include the header that was used to determine the

   sending domain.



3.5.2.  Determining Whether an Email Should Be Signed



   A signer can obviously only sign email for domains for which it has a

   private key and the necessary knowledge of the corresponding public

   key and selector information, however there are a number of other

   reasons why a signer may choose not to sign an email.



   A signer MUST NOT sign an email if the email submission is not

   authorized to use the sending domain.



   A signer MUST NOT sign an email that already contains a "DomainKey-

   Signature:" header unless a "Sender:" header has been added that was

   not included in the original signature.  The most obvious case where

   this occurs is with mailing lists.



   A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.



3.5.3.  Selecting a Private Key and Corresponding Selector Information



   This specification does not define the basis by which a signer should

   choose which private key and selector information to use.  Currently,

   all selectors are equal as far as this specification is concerned, so

   the decision should largely be a matter of administrative

   convenience.



3.5.4.  Calculating the Signature Value



   The signer MUST use one of the defined canonicalization algorithms to

   present the email to the signing algorithm.  Canonicalization is only

   used to prepare the email for signing.  It does not affect the

   transmitted email in any way.



   To avoid possible ambiguity, a signing server may choose to remove

   any pre-existing "DomainKey-Status:" headers from the email prior to

   preparation for signing and transmission.



3.5.5.  Prepending the "DomainKey-Signature:" Header



   The final step in the signing process is that the signer MUST prepend

   the "DomainKey-Signature:" header prior to continuing with the

   process of transmitting the email.







Delany                          Historic                       [Page 21]



RFC 4870                       DomainKeys                       May 2007





3.6.  Policy Statement of Sending Domain



   While the disposition of inbound email is ultimately a matter for the

   receiving system, the introduction of authentication in email creates

   a need for the sender domain to indicate their signing policy and

   preferred disposition of unsigned email, in particular, whether a

   domain is participating in DomainKeys, whether it is testing, and

   whether it signs all outbound email.



   The sending domain policy is very simple and is expressed in the

   _domainkey TXT record in the DNS of the sending domain.  For example,

   in the example.com domain, the record is called

   _domainkey.example.com.



   The contents of this TXT record are stored as tag=value pairs

   separated by semicolons, for example, as in the following:



   _domainkey   IN TXT "t=y; o=-; n=notes; r=emailAddress"



   All tags are optional.  The current valid tags are as follows:



      n = Notes that may be of interest to a human.  No interpretation

          is made by any program.



      o = Outbound Signing policy ("-" means that this domain signs all

          email; "~" is the default and means that this domain may sign

          some email with DomainKeys).



      r = A reporting email address.  If present, this defines the email

          address where invalid verification results are reported.  This

          tag is primarily intended for early implementers -- the

          content and frequency of the reports will be defined in a

          separate document.



      t = a set of flags that define boolean attributes.  Valid

          attributes are as follows:



          y = testing mode.  This domain is testing DomainKeys, and

              unverified email MUST NOT be treated differently from

              verified email.  Recipient systems MAY wish to track

              testing mode results to assist the sender).



          Note that testing mode cannot be turned off by this tag;

          thus, policy cannot revert the testing mode setting of a

          Selector.



          This tag is optional.









Delany                          Historic                       [Page 22]



RFC 4870                       DomainKeys                       May 2007





   (Syntax rules for the tag=value format are discussed in Appendix A.)



   Recipient systems SHOULD only retrieve this policy TXT record to

   determine policy when an email fails to verify or does not include a

   signature.  Recipient systems SHOULD not retrieve this policy TXT

   record for email that successfully verifies.  Note that "testing

   mode" SHOULD also be in the Selector TXT record if the domain owner

   is running a DomainKeys test.



   If the policy TXT record does not exist, recipient systems MUST

   assume the default values.



   There is an important implication when a domain states that it signs

   all email with the "o=-" setting, namely that the sending domain

   prefers that the recipient system treat unsigned mail with a great

   deal of suspicion.  Such suspicion could reasonably extend to

   rejecting such email.  A verifying system MAY reject unverified email

   if a domain policy indicates that it signs all email.



   Of course, nothing compels a recipient MTA to abide by the policy of

   the sender.  In fact, during the trial, a sending domain would want

   to be very certain about setting this policy, as processing by

   recipient MTAs may be unpredictable.  Nonetheless, a domain that

   states that it signs all email MUST expect that unverified email may

   be rejected by some receiving MTAs.



3.7.  The Verification Process



   There is no defined or recommended limit on the lifetime of a

   selector and corresponding public key; however, it is recommended

   that verification occur in a timely manner with the most timely place

   being during acceptance or local delivery by the MTA.



   Verifying a signature consists of the following three steps:



      o  extract signature information from the headers



      o  retrieve the public key based on the signature information



      o  check that the signature verifies against the contents



   In the event that any of these steps fails, the sending domain policy

   is ascertained to assist in applying local policy.

















Delany                          Historic                       [Page 23]



RFC 4870                       DomainKeys                       May 2007





3.7.1.  Presumption that Headers Are Not Reordered



   Indications from deployment of previous versions of this

   specification suggest that the canonicalization algorithms in

   conjunction with the "h" tag in the "DomainKey-Signature:" header

   allows most email to cryptographically survive intact between signing

   and verifying.



   The one assumption that most of the early deployments make is that

   the headers included in the signature are not reordered prior to

   verification.



   While nothing in this specification precludes a verifier from

   "looking" for a header that may have been reordered, including being

   moved to a position prior to the "DomainKey-Signature:" header, such

   reordered email is unlikely to be successfully verified by most

   implementations.



   A second consequence of this assumption -- particularly in the

   presence of multiple "DomainKey-Signature:" headers -- is that the

   first "DomainKey-Signature:" header in the email was the last

   signature added to the email and thus is the one to be verified.



3.7.2.  Verification Should Render a Binary Result



   While the symptoms of a failed verification are obvious -- the

   signature doesn't verify -- establishing the exact cause can be more

   difficult.  If a selector cannot be found, is that because the

   selector has been removed, or was the value changed somehow in

   transit? If the signature line is missing, is that because it was

   never there, or was it removed by an overzealous filter?



   For diagnostic purposes, the exact reason why the verification fails

   SHOULD be recorded; however, in terms of presentation to the end

   user, the result SHOULD be presented as a simple binary result:

   either the email is verified or it is not.  If the email cannot be

   verified, then it SHOULD be rendered the same as all unverified email

   regardless of whether or not it looks like it was signed.



3.7.3.  Selecting the Most Appropriate "DomainKey-Signature:" Header



   In most cases, a signed email is expected to have just one signature

   -- that is, one "DomainKey-Signature:" header.  However, it is

   entirely possible that an email can contain multiple signatures.  In

   such cases, a verifier MUST find the most appropriate signature to

   use and SHOULD ignore all other signatures.











Delany                          Historic                       [Page 24]



RFC 4870                       DomainKeys                       May 2007





   The process of finding the most appropriate signature consists of the

   following "best match" rules.  The rules are to be evaluated in

   order.



      1. Selecting the sending domain



         If the email contains a "Sender:" header, the sending domain is

         extracted from the "Sender:" address.  If this extraction

         fails, the email SHALL fail verification.



         If no "Sender:" header is present, the sending domain is

         extracted from the first address of the "From:" header.  If

         this extraction fails, the email SHALL fail verification.



      2. Domain matching



         A signature can only match if the sending domain matches the

         "d" tag domain -- according to the "d" tag subdomain matching

         rules.



      3. "h" tag matching



         If the signature contains the "h" tag list of headers, that

         list must include the header used to extract the sending domain

         in rule 1, above.



      4. Most secure signing algorithm



         While it is not yet the case, in the event that additional

         algorithms are added to this specification, a verifier MUST use

         the signature that contains the most secure algorithm as

         defined by the future specification.  For current

         implementations, that means verifiers MUST ignore signatures

         that are coded with an unrecognized signing algorithm.



      5. Earlier signatures are preferred



         If multiple signatures are equal as far as these rules apply,

         the signature from the earlier header MUST be used in

         preference to later signature headers.



   Implementors MUST meticulously validate the format and values in the

   "DomainKey-Signature:" header; any inconsistency or unexpected values

   MUST result in ignoring that header.  Being "liberal in what you

   accept" is definitely a bad strategy in this security context.













Delany                          Historic                       [Page 25]



RFC 4870                       DomainKeys                       May 2007





   In all cases, if a verification fails, the "DomainKey-Status:" header

   SHOULD be generated and include a message to help explain the reason

   for failure.



3.7.4.  Retrieve the Public Key Based on the Signature Information



   The public key is needed to complete the verification process.  The

   process of retrieving the public key depends on the query type as

   defined by the "q" tag in the "DomainKey-Signature:" header line.

   Obviously, a public key should only be retrieved if the process of

   extracting the signature information is completely successful.



   Currently, the only valid query type is "dns".  The public key

   retrieval process for this type is as follows:



      1. Using the selector name defined by the "s" tag, the

         "_domainkey" namespace and the domain name defined by the "d"

         tag, construct and issue the DNS TXT record query string.



         For example, if s=brisbane and d=example.net, the query string

         is "brisbane._domainkey.example.net".



      2. If the query for the public key fails to respond, the verifier

         SHOULD defer acceptance of this email (normally this will be

         achieved with a 4XX SMTP response code).



      3. If the query for the public key fails because the corresponding

         data does not exist, the verifier MUST treat the email as

         unverified.



      4. If the result returned from the query does not adhere to the

         format defined in this specification, the verifier MUST treat

         the email as unverified.



      5. If the public key data is not suitable for use with the

         algorithm type defined by the "a" tag in the "DomainKey-

         Signature:" header, the verifier MUST treat the email as

         unverified.



   Implementors MUST meticulously validate the format and values

   returned by the public key query.  Any inconsistency or unexpected

   values MUST result in an unverified email.  Being "liberal in what

   you accept" is definitely a bad strategy in this security context.



   Latency critical implementations may wish to initiate the public key

   query in parallel with calculating the SHA-1 hash, as the public key

   is not needed until the final RSA is calculated.









Delany                          Historic                       [Page 26]



RFC 4870                       DomainKeys                       May 2007





3.7.5.  Verify the Signature



   Armed with the signature information from the "DomainKey-Signature:"

   header and the public key information returned by the query, the

   signature of the email can now be verified.



   The canonicalization algorithm defined by the "c" tag in the

   "DomainKey-Signature:" header defines how the data is prepared for

   the verification algorithm, and the "a" tag in the same header

   defines which verification algorithm to use.



3.7.6.  Retrieving Sending Domain Policy



   In the event that an email fails to verify, the policy of the sending

   domain MUST be consulted.  For now, that means consulting the

   _domainkey TXT record in the DNS of the domain in the sending domain

   as defined in Section 3.5.1.  For example, if example.net is the

   sending domain the TXT query is:



      _domainkey.example.net



   A verifier SHOULD consider the sending domain policy statement and

   act accordingly.  The range of possibilities is up to the receiver,

   but it MAY include rejecting the email.



3.7.7.  Applying Local Policy



   After all verification processes are complete, the recipient system

   has authentication information that can help it decide what to do

   with the email.



   It is beyond the scope of this specification to describe what actions

   a recipient system should take, but an authenticated email presents

   an opportunity to a receiving system that unauthenticated email

   cannot.  Specifically, an authenticated email creates a predictable

   identifier by which other decisions can reliably be managed, such as

   trust and reputation.



   Conversely, unauthenticated email lacks a reliable identifier that

   can be used to assign trust and reputation.  It is not unreasonable

   to treat unauthenticated email as lacking any trust and having no

   positive reputation.



3.8.  Conveying Verification Results to MUAs



   Apart from the application of automated policy, the result of a

   signature verification should be conveyed to the user reading the

   email.







Delany                          Historic                       [Page 27]



RFC 4870                       DomainKeys                       May 2007





   Most email clients can be configured to recognize specific headers

   and apply simple rules, e.g., filing into a particular folder.  Since

   DomainKey signatures are expected to be initially verified at the

   border MTA, the results of the verification need to be conveyed to

   the email client.  This is done with the "DomainKey-Status:" header

   line prepended to the email.



   The "DomainKey-Status:" header starts with a string that indicate the

   result of the verification.  Valid values are as follows:



   "good"         - the signature was verified at the time of testing

   "bad"          - the signature failed the verification

   "no key"       - the public key query failed as the key does not

                    exist

   "revoked"      - the public key query failed as the key has been

                    revoked

   "no signature" - this email has no "DomainKey-Signature:" header

   "bad format"   - the signature or the public key contains unexpected

                    data

   "non-participant" - this sending domain has indicated that it does

                       not participate in DomainKeys



   Verifiers may append additional data that expands on the reason for

   the particular status value.



   A client SHOULD just look for "good" and assume that all other values

   imply that the verification could not be performed for some reason.

   Policy action as a consequence of this header is entirely a local

   matter.



   Here are some examples:



      DomainKey-Status: good

      DomainKey-Status: bad format



   Although it is expected that MTAs will be DomainKey aware before

   MUAs, it is nonetheless possible that a DomainKey-aware MUA can be

   fooled by a spoofed "DomainKey-Status:" header that passes through a

   non-DomainKey-aware MTA.



   If this is perceived to be a serious problem, then it may make sense

   to preclude the "good" value and only have values that effectively

   demote the email as far as the UA is concerned.  That way successful

   spoofing attempts can only serve to demote themselves.















Delany                          Historic                       [Page 28]



RFC 4870                       DomainKeys                       May 2007





4.  Example of Use



   This section shows the complete flow of an email from submission to

   final delivery, demonstrating how the various components fit

   together.



4.1.  The User Composes an Email



   From: "Joe SixPack" <joe@football.example.com>

   To: "Suzie Q" <suzie@shopping.example.net>

   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" <joe@football.example.com>

   To: "Suzie Q" <suzie@shopping.example.net>

   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" <joe@football.example.com>

   To: "Suzie Q" <suzie@shopping.example.net>

   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" <statements@largebank.example.com>

      To: "Suzie Q" <suzie@shopping.example.net>

      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]



