[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5585

DomainKeys Identified Mail                                     T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Informational                                D. Crocker
Expires: May 14, 2008                        Brandenburg InternetWorking
                                                         P. Hallam-Baker
                                                           VeriSign Inc.
                                                       November 11, 2007


           DomainKeys Identified Mail (DKIM) Service Overview
                      draft-ietf-dkim-overview-06

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   DomainKeys Identified Mail (DKIM) allows an organization to take
   responsibility for a message, in a way that can be validated by a
   recipient.  The organization can be the author's, the originating
   sending site, an intermediary, or one of their agent's.  DKIM defines
   a domain-level digital signature authentication framework for email,



Hansen, et al.            Expires May 14, 2008                  [Page 1]

Internet-Draft            DKIM Service Overview            November 2007


   using public-key cryptography and key server technology.  This
   permits verifying the signer of a message, as well as the integrity
   of its contents.  The ultimate goal of this framework is to permit a
   signing domain to assert responsibility for a message, thus proving
   and protecting the identity associated with the message and the
   integrity of the messages itself, while retaining the functionality
   of Internet email as it is known today.  Such protection of email
   identity can assist in the global control of "spam" and "phishing".
   This document provides an overview of the DKIM service and describes
   how it can fit into a messaging service.  It also describes how DKIM
   relates to other IETF message signature technologies.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Prior Work . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Discussion Venue . . . . . . . . . . . . . . . . . . . . .  5
   2.  Internet Mail Background . . . . . . . . . . . . . . . . . . .  5
     2.1.  Administrative Management Domain (ADMD)  . . . . . . . . .  6
     2.2.  DKIM Placement within an ADMD  . . . . . . . . . . . . . .  8
   3.  The DKIM Value Proposition . . . . . . . . . . . . . . . . . .  8
   4.  The Role of Trust  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Functional Goals . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Operational Goals  . . . . . . . . . . . . . . . . . . . . 11
   6.  DKIM Function  . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  The Basic Signing Service  . . . . . . . . . . . . . . . . 13
     6.2.  Characteristics of a DKIM signature  . . . . . . . . . . . 13
     6.3.  The Selector construct . . . . . . . . . . . . . . . . . . 13
     6.4.  Verification . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Service Architecture . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Administration and Maintenance . . . . . . . . . . . . . . 16
     7.2.  Signing  . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.3.  Verifying  . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.4.  Unverified or Unsigned Mail  . . . . . . . . . . . . . . . 17
     7.5.  Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Informative References . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20








Hansen, et al.            Expires May 14, 2008                  [Page 2]

Internet-Draft            DKIM Service Overview            November 2007


1.  Introduction

   DomainKeys Identified Mail (DKIM) allows an organization to take
   responsibility for a message, in a way that can be validated by a
   recipient.  The organization can be the author's, the originating
   sending site, an intermediary, or one of their agent's.  DKIM defines
   a domain-level digital signature authentication framework for email,
   using public-key cryptography and key server technology.  This
   permits verifying the signer of a message, as well as the integrity
   of its contents.  DKIM accomplishes this by defining a domain-level
   authentication framework for email using public-key cryptography and
   key server technology [RFC4871].  This permits verifying a message
   source, an intermediary, or one of their agents, as well as the
   integrity of its contents.  DKIM will also provide a mechanism that
   permits potential email signers to publish information about their
   email signing practices; this will permit email receivers to make
   additional assessments of unsigned messages.

   The ultimate goal of this framework is to permit a domain to assert
   responsibility for a message, thus proving and protecting the
   identity associated with the message and the integrity of the
   messages itself, while retaining the functionality of Internet email
   as it is known today.  Such protection of email identity, can assist
   in the global control of "spam" and "phishing".

   This document provides a description of DKIM's architecture and
   functionality.  It is intended for those who are adopting,
   developing, or deploying DKIM.  It also will be helpful for those who
   are considering extending DKIM, either into other areas of use or to
   support additional features.  This Overview does not provide
   information on threats to DKIM or email, or details on the protocol
   specifics, which can be found in [RFC4871] and [RFC4686],
   respectively.  The document assumes a background in basic network
   security technology and services.

   Neither this document nor DKIM attempt to provide solutions to the
   world's problems with spam, phishing, virii, worms, joe jobs, etc.
   DKIM provides one basic tool, in what needs to be a large arsenal,
   for improving basic trust in the Internet mail service.  However by
   itself, DKIM is not sufficient to that task and this Overview does
   not pursue the issues of integrating DKIM into these larger efforts,
   beyond a simple reference within a system diagram.  Rather, it is a
   basic introduction to the technology and its use.

1.1.  Prior Work

   Historical email assessment based on identity has been based on the
   IP Address of a system that sent the message.  The Address is



Hansen, et al.            Expires May 14, 2008                  [Page 3]

Internet-Draft            DKIM Service Overview            November 2007


   obtained via underlying Internet information mechanisms and is
   therefore trusted to be accurate.  Besides having some known security
   weaknesses, the use of Addresses present a number of functional and
   operational problems.  Consequently there is an industry desire to
   use a more stable value that has better correspondence to
   organizational boundaries.  Domain Names are viewed as satisfying
   this need.

   There have been four previous efforts at standardizing an Internet
   email signature scheme:

   o  Privacy Enhanced Mail (PEM) was first published in 1987.
      [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services
      (MOSS) in 1995.  [RFC1848] Today, these two are only of historical
      interest.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
      first released in 1991.  [RFC1991] A later version was
      standardized as OpenPGP.  [RFC2440] [RFC3156]
      [I-D.ietf-openpgp-rfc2440bis]

   o  RSA Security independently developed Secure MIME (S/MIME) to
      transport a PKCS #7 data object.  [RFC3851]

   Development of S/MIME and OpenPGP have continued.  While both have
   achieved a significant user base, neither have achieved ubiquity in
   deployment or use, and their goals differ from those of DKIM.

   To the extent that other message-signing services might have been
   adapted to do the job that DKIM is designed to perform, it was felt
   that re-purposing any of those would be more problematic than
   creating a separate service.  That said, DKIM uses security algorithm
   components that have a long history, including use within some of
   those other messaging security services.

   DKIM has a distinctive approach for distributing and vouching for
   keys.  It uses a key-centric Public Key Infrastructure (PKI) rather
   than the more typical approaches based on a certificate in the styles
   of Kohnfelder (X.509) or Zimmermann (web of trust).  For DKIM, the
   owner of a key asserts its validity, rather than relying on the key
   having a broader semantic implication of the assertion, such as a
   quality assessment of the key's owner.  DKIM treats quality
   assessment as an independent, value-added service, beyond the initial
   work of deploying a verifying signature service.

   Further, DKIM's PKI is supported by adding additional information



Hansen, et al.            Expires May 14, 2008                  [Page 4]

Internet-Draft            DKIM Service Overview            November 2007


   records to the existing Domain Name System (DNS) [RFC1034], rather
   than requiring deployment of a new query infrastructure.  This
   approach has significant operational advantages.  First, it avoids
   the considerable barrier of creating a new infrastructure; hence it
   leverages a global base of administrative experience and highly
   reliable distributed operation.  Second, the technical aspect of the
   DNS is already known to be efficient.  Any new service would have to
   undergo a period of gradual maturation, with potentially problematic
   early-stage behaviors.  By (re-)using the DNS, DKIM avoids these
   growing pains.

1.2.  Discussion Venue

   NOTE TO RFC EDITOR:   This "Discussion Venue" section is to be
      removed prior to publication.

   This document is being discussed on the DKIM mailing list,
   ietf-dkim@mipassoc.org.


2.  Internet Mail Background

   Internet Mail has a simple split between the user world, in the form
   of Mail User Agents (MUA), and the transmission world, in the form of
   the Mail Handling Service (MHS) composed of Mail Transfer Agents
   (MTA).  The MHS is responsible for accepting a message from one user,
   the author, and delivering it to one or more other users, the
   recipients.  This creates a virtual MUA-to-MUA exchange environment.
   The first component of the MHS is called the Mail Submission Agent
   (MSA) and the last is called the Mail Delivery Agent (MDA).

   An email Mediator is both an inbound MDA and outbound MSA.  It takes
   delivery of a message and reposts it for further distribution,
   retaining the original From header field.  A mailing list is a common
   example of a Mediator

   The modern Internet Mail service is marked by many independent
   operators, many different components for providing users with service
   and many other components for performing message transfer.
   Consequently, it is necessary to distinguish administrative
   boundaries that surround sets of functional components, which are
   subject to coherent operational policies.

   As expanded on below, every MSA is a candidate for signing using
   DKIM, and every MDA is a candidate for doing DKIM verification.






Hansen, et al.            Expires May 14, 2008                  [Page 5]

Internet-Draft            DKIM Service Overview            November 2007


2.1.  Administrative Management Domain (ADMD)

   Operation of Internet Mail services is apportioned to different
   providers (or operators).  Each can be composed of an independent
   ADministrative Management Domain (ADMD).  An ADMD operates with an
   independent set of policies and interacts with other ADMDs according
   to differing types and amounts of trust.  Examples include: an end-
   user operating their desktop client that connects to an independent
   email service, a department operating a submission agent or a local
   Relay, an organization's IT group that operates enterprise Relays,
   and an ISP operating a public shared email service.

   Each of these can be configured into many combinations of
   administrative and operational relationships, with each ADMD
   potentially having a complex arrangement of functional components.
   Figure 1 depicts the relationships among ADMDs.  Perhaps the most
   salient aspect of an ADMD is the differential trust that determines
   its policies for activities within the ADMD, versus those involving
   interactions with other ADMDs.

   Basic types of ADMDs include:



      Edge:   Independent transfer services, in networks at the edge of
         the Internet Mail service.

      User:   End-user services.  These might be subsumed under an Edge
         service, such as is common for web-based email access.

      Transit:   These are Mail Service Providers (MSP) offering value-
         added capabilities for Edge ADMDs, such as aggregation and
         filtering.


















Hansen, et al.            Expires May 14, 2008                  [Page 6]

Internet-Draft            DKIM Service Overview            November 2007


   Note that Transit services are quite different from packet-level
   transit operation.  Whereas end-to-end packet transfers usually go
   through intermediate routers, email exchange across the open Internet
   is often directly between the Edge ADMDs, at the email level.

   +--------+                            +--------+    +--------+
   | ADMD#1 |                            | ADMD#3 |    | ADMD#4 |
   | ------ |                            | ------ |    | ------ |
   |        |   +----------------------->|        |    |        |
   | User   |   |                        |--Edge--+--->|--User  |
   |  |     |   |                   +--->|        |    |        |
   |  V     |   |                   |    +--------+    +--------+
   | Edge---+---+                   |
   |        |   |    +----------+   |
   +--------+   |    |  ADMD#2  |   |
                |    |  ------  |   |
                |    |          |   |
                +--->|-Transit--+---+
                     |          |
                     +----------+

        Figure 1: ADministrative Management Domains (ADMD) Example

   In Figure 1, ADMD numbers 1 and 2 are candidates for doing DKIM
   signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM
   verification.

   The distinction between Transit network and Edge network transfer
   services is primarily significant because it highlights the need for
   concern over interaction and protection between independent
   administrations.  The interactions between functional components
   within an ADMD are subject to the policies of that domain.

   Common ADMD examples are:



         Enterprise Service Providers:

            Operators of an organization's internal data and/or mail
            services.

         Internet Service Providers:

            Operators of underlying data communication services that, in
            turn, are used by one or more Relays and Users.  It is not
            necessarily their job to perform email functions, but they
            can, instead, provide an environment in which those



Hansen, et al.            Expires May 14, 2008                  [Page 7]

Internet-Draft            DKIM Service Overview            November 2007


            functions can be performed.

         Mail Service Providers:

            Operators of email services, such as for end-users, or
            mailing lists.

2.2.  DKIM Placement within an ADMD

   It is expected that the most common venue for a DKIM implementation
   will be within the infrastructures of the originating organization's
   outbound service and and the receiving organization's inbound
   service, such as a department or a boundary MTA.  DKIM can be
   implemented in an author's or recipient MUA, but this is expected to
   be less typical, since it has higher administration and support
   costs.

   A Mediator, such as a mailing list, often can re-post a message
   without breaking the DKIM signature.  Furthermore it can add its own
   signature.  This can be added by the Mediator software itself, or by
   any outbound component in the Mediator's ADMD.


3.  The DKIM Value Proposition

   The nature and origins of a message are often falsely stated.  As a
   foundation for distinguishing legitimate mail, DKIM provides a means
   of associating a verifiable identity with a message.  Given the
   presence of that identity, a receiver can make decisions about
   further handling of the message, based upon assessments of that
   identity.

   Receivers who successfully verify a signature can use information
   about the signer as part of a program to limit spam, spoofing,
   phishing, or other undesirable behavior.  DKIM does not, itself,
   prescribe any specific actions by the recipient; rather it is an
   enabling technology for services that do.

   These services will typically:

   1.  Verify an identity

   2.  Determine whether the identity is known or unknown

   3.  Determine whether a known identity is trusted

   The role of DKIM is in the first two of these; DKIM is an enabler for
   the third.



Hansen, et al.            Expires May 14, 2008                  [Page 8]

Internet-Draft            DKIM Service Overview            November 2007


   An attack is made against an organization or against customers of an
   organization.  The name of the organization is linked to particular
   Internet domain names.  One point of leverage used by attackers is
   either to spoof a legitimate domain name, or to use a "cousin" name
   that is similar to one that is legitimate, but is not controlled by
   the target organization.  A DKIM-based accreditation service can
   enforce a basic separation between domains used by such known
   organizations and domains used by others.

   DKIM signatures can be created by a direct handler of a message,
   either as its originator or as an intermediary.  It can also be
   created by an independent service, providing assistance to a handler
   of the message.  Whoever does the signing chooses the domain name to
   be used as the basis for later assessments.  Hence, reputation
   associated with that domain name is the basis for evaluating whether
   to trust the message for delivery.  The owner of the domain name
   being used for a DKIM signature is declaring that they are
   accountable for the message.

   DKIM is intended to be a value-added feature for email.  Mail that is
   not signed by DKIM is handled in the same way as it was, before DKIM
   was defined; it continues to be evaluated by established analysis and
   filtering techniques.  Over time, widespread DKIM adoption could
   permit more strict handling of messages that are not signed.  However
   early benefits do not require this and probably do not warrant this.

   It is important to be clear about the narrow scope of DKIM's
   capabilities.  It is an enabling technology, intended for use in the
   larger context of determining message legitimacy.  This larger
   context is complex, so that it is easy to assume that a component
   like DKIM, which actually provides only a limited service, instead
   satisfies the broader set of requirements.  A DKIM signature:

   o  Does not offer any assertions about the behaviors of the identity
      doing the signing.

   o  Does not prescribe any specific actions for receivers to take upon
      successful signature verification.

   o  Does not provide protection after signature verification.

   o  Does not protect against re-sending (replay of) a message that
      already has a verified signature; therefore a transit intermediary
      or a recipient can re-post the message in such a way that the
      signature would remain verifiable, although the new recipient(s)
      would not have been specified by the author.





Hansen, et al.            Expires May 14, 2008                  [Page 9]

Internet-Draft            DKIM Service Overview            November 2007


4.  The Role of Trust

   As mentioned above, DKIM lets you verify the identity of a signer and
   is an enabler for determining whether a now-known identity is
   trusted; it does not itself provide that determination.  Deciding
   whether a non-known identity can be trusted must be handled by
   accreditation and reputation services that are themselves trustable.

   An accreditation service provides an assessment of a sender's
   trustworthiness on behalf of the sender.  They reflect the statement
   "this signer says they are good and I concur with that statement."
   Accreditation services are almost always network-based.

   A reputation service provides an assessment of a sender's
   trustworthiness on behalf of the receiver.  They reflect the
   statements "based on their past history or some private knowledge
   about them, this signer can be trusted" or "not trusted."  Reputation
   services can be network-based or be based on local white lists and
   black lists.


5.  DKIM Goals

   DKIM adds an end-to-end authentication mechanism to the existing
   email transfer infrastructure.  This motivates functional goals about
   authentication and operational goals about integration with the
   existing email service.

5.1.  Functional Goals

5.1.1.  Use Domain-level granularity for assurance.

   OpenPGP and S/MIME apply the end-to-end principle in terms of
   individual originators and recipients, notably using full email
   addresses.  DKIM seeks accountability at the more coarse granularity
   of an organization or, perhaps, a department.  An existing Internet
   service construct that enables this granularity is the Domain Name
   [RFC1034], to which the signing key record is bound.  Further DKIM
   signing and/or validating can be implemented anywhere along the
   transit path, rather than only in the end systems or only in the
   boundary MTA.

5.1.2.  Allow delegation of signing to independent parties.

   Different parties have different roles in the process of email
   exchange.  Some are easily visible to end users and others are
   primarily visible to operators of the service.  DKIM needs to support
   signing by any of these different parties and needs to permit them to



Hansen, et al.            Expires May 14, 2008                 [Page 10]

Internet-Draft            DKIM Service Overview            November 2007


   sign with any domain name that they deem appropriate (and for which
   they are authorized.)  As an example an organization that creates
   email content often delegates portions of its processing or
   transmission to an outsourced group.  DKIM supports this mode of
   activity, in a manner that is not visible to end users.

5.1.3.  Distinguish the core authentication mechanism from its
        derivative uses.

   An authenticated identity can be subject to a variety of processing
   policies, either ad hoc or standardized.  The only semantics inherent
   to a DKIM signature is that the signer is asserting (some)
   responsibility for the message.  All other mechanisms and meanings
   are independent of this core service.  One such mechanism might
   assert a relationship between the signing identity and the author, as
   specified in the From header field's domain identity[RFC2822].
   Another might specify how to treat an unsigned message with that From
   field domain.

5.1.4.  Retain ability to have anonymous email.

   The ability to send a message that does not identify its author is
   considered to be a valuable quality of the current email service that
   needs to be retained.  DKIM is compatible with this goal since it
   permits an email system operator to be authenticated, rather than the
   content author.  Knowing that a message definitely came from
   example.com does not threaten the anonymity of the user who authored
   it, if it is still possible to obtain effectively anonymous accounts
   at example.com.

5.2.  Operational Goals

5.2.1.  Treat verification failure the same as no signature present.

   OpenPGP and S/MIME were both designed for strong cryptographic
   protection.  This included treating verification failure as message
   failure.  As a sub-goal to the requirement for transparency, a DKIM
   signature verifier is to treat messages with signatures that fail as
   if they were unsigned.  Hence the message will revert to normal
   handling, through the receiver's existing filtering mechanisms.
   Thus, a sender cannot apply a broken signture and force a message to
   be treated any differently than if the signature weren't there.

5.2.2.  Make signatures transparent to non-supporting recipients.

   S/MIME and OpenPGP both modify the message body.  Hence, their
   presence is potentially visible to email recipients and their user
   software needs to process the associated constructs.  In order to



Hansen, et al.            Expires May 14, 2008                 [Page 11]

Internet-Draft            DKIM Service Overview            November 2007


   facilitate incremental adoption, DKIM is designed to be transparent
   to recipients that do not support it.  A DKIM signature cannot "get
   in the way" for such recipients.

5.2.3.  Permit incremental adoption for incremental benefit.

   DKIM can immediately provide benefits between any two organizations
   that exchange email and implement DKIM.  In the usual manner of
   "network effects", the benefits of DKIM increase dramatically as its
   adoption increases.

   Although it is envisioned that this mechanism will call upon
   independent services to aid in the assessment of DKIM results, they
   are not essential in order to obtain initial benefit.  For example
   DKIM allows (possibly large) pair-wise sets of email providers and
   spam filtering companies to distinguish mail that is associated with
   a known organization, from mail that might deceptively purport to
   have the affiliation.  This in turn allows the development of
   "whitelist" schemes whereby authenticated mail from a known source
   with good reputation is allowed to bypass some spam filters.

   In effect the email receiver is using their set of known
   relationships to generate their own reputation data.  This works
   particularly well for traffic between large sending providers and
   large receiving providers.  However it also works well for any
   operator, public or private, that has mail traffic dominated by
   exchanges among a stable set of organizations.

5.2.4.  Minimize the amount of required infrastructure

   A new service, or an enhancement to an existing service, requires
   adoption by some number of systems, before it can be useful.  The
   greater the number of required adopters, the higher the adoption
   barrier.  This becomes particularly serious when adoption is required
   by intermediary -- that is, infrastructure -- service providers.  In
   order to allow early adopters to gain early benefit, DKIM makes no
   changes to the core Internet Mail service and, instead, can provide a
   useful benefit for any signer/verifier pair of participants
   exchanging mail.  Similarly, DKIM's reliance on the Domain Name
   System greatly reduces the amount of new administrative
   infrastructure that is need, across the open Internet.

5.2.5.  Permit wide range of deployment choices.

   DKIM can be deployed at a variety of places within an organization's
   email service.  This permits the organization to choose how much or
   how little they want DKIM to be part of their service, rather than
   part of a more localized operation.



Hansen, et al.            Expires May 14, 2008                 [Page 12]

Internet-Draft            DKIM Service Overview            November 2007


6.  DKIM Function

   DKIM has a very constrained set of capabilities, primarily targeting
   email while it is in transit, from an author to a set of recipients.
   It creates the ability to associate verifiable information with a
   message, especially a responsible identity.  When a message is not
   signed, DKIM permits the identity of the sender to be used for
   obtaining information about their signing practices.

6.1.  The Basic Signing Service

   With the DKIM signature mechanism, a signer chooses a signing
   identity based on their domain name, performs digital signing on the
   message, and records signature information in a DKIM header field.  A
   verifier obtains the domain name and the "selector" from the DKIM
   header field, queries for a public key associated with the name, and
   verifies the signature.

   DKIM permits any domain name to be used for signing, and supports
   extensible choices for various algorithms.  As is typical for
   Internet standards, there is a core set of algorithms that all
   implementations are required to support, in order to guarantee basic
   interoperability.  This ensures an initial ability to interoperate.

   DKIM permits restricting the use of a signature key to particular
   types of services, such as only for email.  This is helpful when
   delegating signing authority, such as to a particular department or
   to a third-party outsourcing service.

   With DKIM the signer explicitly lists the headers that are signed.
   By choosing the minimal set of headers needed, the signature is
   likely to be considerably more robust against the handling the
   vagaries of intermediary MTAs.

6.2.  Characteristics of a DKIM signature

   A DKIM signature covers the message body and selected header fields.
   The signer computes a hash of the selected header fields and another
   hash of the body.  The signer then uses a private key to
   cryptographically encode this information, along with other signing
   parameters.  Signature information is placed into a new [RFC2822]
   header field of the message.

6.3.  The Selector construct

   A signature is associated with a domain name, as specified in the
   "i=" (or "d=" if "i=" is not present) DKIM-Signature header field
   parameters.  That domain name is the complete identity used for



Hansen, et al.            Expires May 14, 2008                 [Page 13]

Internet-Draft            DKIM Service Overview            November 2007


   making assessments about the signer.  However this name is not
   sufficient for making a DNS query to obtain the key needed to verify
   the signature.

   A single domain can use multiple signing keys and/or multiple
   signers.  To support this, DKIM identifies a particular signature as
   a combination of the domain name and an added field, called the
   "selector", coded into separate DKIM-Signature header field
   parameters.

   NOTE:   The selector is not intended to be part of the domain name
      that is used for making assessments.  Rather, the selector is
      strictly reserved for use in administering keys that are
      associated with the domain name.  If the selector becomes part of
      a name assessment mechanism, then there is no remaining mechanism
      for making a transition from an old, or compromised, key to a new
      one.

   Signers often need to support multiple assessments about their
   organization, such as to distinguish one type of message from
   another, or one portion of the organization from another.  To permit
   assessments that are independent, one method is for an organization
   to use different sub-domains in the "d=" parameter, such as
   "transaction.example.com" versus "newsletter.example.com", or
   "productA.example.com" versus "productB.example.com".

6.4.  Verification

   After a message has been signed, any agent in the message transit
   path can verify the signature, to determine that the signing identity
   took responsibility for the message.  Message recipients can verify
   the signature by querying the DNS for the signer's domain directly,
   to retrieve the appropriate public key, and thereby confirm that the
   message was attested to by a party in possession of the private key
   for the signing domain.  Typically, verification will be done by an
   agent in the ADMD of the message recipient.


7.  Service Architecture

   The DKIM service is divided into components that can be performed
   using different, external services, such as for key retrieval.
   However the basic DKIM signing specification defines an initial set
   of these services, in order to ensure a basic level of
   interoperability.






Hansen, et al.            Expires May 14, 2008                 [Page 14]

Internet-Draft            DKIM Service Overview            November 2007


                           |
                           |- RFC2822 Message
                           V
            +------------------------------------+
            | ORIGINATING OR RELAYING ADMD (MSA) |
            |                                    |
        +..>| Sign Message                       |
        .   +--------------+---------------------+
        .                  |
        .private           |
    +---+---+              |
    |  Key  |              |                    +-----------+
    | Store |          [Internet]               |  Sender   |
    +---+---+              |                    | Practices |
        .public            |                    +-----+-----+
        .                  V                          .
        .   +-----------------------------------+     .
        .   | RELAYING OR DELIVERING ADMD (MDA) |     .
        .   |                                   |     .
        .   | Message Signed?                   |     .
        .   +-------+----------------+----------+     .
        .           |yes             |no              .
        .           V                V                .
        .      +-----------+     +-----------+        .
        +.....>| Verify    | +-->| Check     |<.......+
               | Signature | |   | Practices |<.......+
               +---+-----+-+ |   +---+-------+        .
                   |     |   |       |                .
                   |     +---+       |                .
                   |pass  fail       |                .
                   V                 |          +-----+-----+
               +--------+            |          |  Local    |
      +.......>| Assess |            |          |  Sender   |
      .        | Signer |            |          | Practices |
      .        +---+----+            |          +-----------+
      .  assessment|                 |
      .            +------+   +------+
      .                   |   |
    +-+-----------+       V   V
    | Reputation/ |   +-----------+
    |Accreditation|   | Message   |
    |    Info     |   | Filtering |
    +-----+-------+   | Engine    |
                      +-----------+>

                    Figure 2: DKIM Service Architecture

   As shown in Figure 2, basic message processing is divided between the



Hansen, et al.            Expires May 14, 2008                 [Page 15]

Internet-Draft            DKIM Service Overview            November 2007


   MSA and the MDA.

   The MSA  The MSA signs the message, using private information from
      the Key Store.

   The MDA  The MDA verifies the signature or determines whether a
      signature was required.  Verifying the signature uses public
      information from the Key Store.  If the signature passes,
      reputation information is used to asses the signer and that
      information is passed to the message filtering system.  If the
      signature fails or there is no signature, information about the
      sender's practices is retrieved remotely and/or locally, and that
      information is passed to the message filtering system.

   Note:  Figure 2 does not show the affects on the flow of multiple
      signatures or third-party signatures.

7.1.  Administration and Maintenance

   A number of tables and services are used to provide external
   information.  Each of these introduces administration and maintenance
   requirements.

   Key Store  DKIM uses public/private (asymmetric) key technology.  The
      signer users a private key and the validator uses the
      corresponding public key.  The current DKIM signing specification
      provides for querying the Domain Names Service (DNS), to permit a
      validator to obtain the public key.  The signing organization
      therefore must have a means of adding a key to the DNS, for every
      selector/domain-name combination.  Further, the signing
      organization needs policies for distributing and revising keys.

   Sender Practices  If a message contains a valid signature, then the
      verifier can evaluate the associated domain name's reputation.  If
      a message does not contain a valid signature, that fact could be
      useful, if the verifier can discover information about the DKIM-
      related practices of one of the agents purportedly involved with
      the message, such as the domain listed in the author's FROM header
      field.  Such information might come from tables developed through
      private agreement or from standards-based mechanisms.  As they are
      defined, each domain name owner will need to consider what
      information to publish through the mechanism and then will need to
      create and maintain it.

   Reputation/Accreditation  "Reputation/Accreditation" provides
      quality-assessment information that is associated with a domain
      name, and comes in many forms and from many sources.  DKIM does
      not define these services.  It's relevance to them is to provide a



Hansen, et al.            Expires May 14, 2008                 [Page 16]

Internet-Draft            DKIM Service Overview            November 2007


      validated domain name, upon which assessments can be made.

7.2.  Signing

   Signing can be performed by a component of the ADMD that creates the
   message, and/or within any ADMD, along the relay path.  The signer
   uses the appropriate private key.

7.3.  Verifying

   Verification can be performed by any functional component along the
   relay and delivery path.  Verifiers retrieve the public key based
   upon the parameters stored in the message.

7.4.  Unverified or Unsigned Mail

   Note that a failed signature causes the message to be treated in the
   same manner as one that is unsigned.  Messages lacking a valid
   originator signature (a signature associated with the originator of
   the message as opposed to a signature associated with an
   intermediary) prompt a query for any published "sender practices"
   information, as an aid in determining whether the sender information
   has been used without authorization.

7.5.  Evaluating

   The Figure shows the verified identity as being used to assess an
   associated reputation, but it could be applied for other tasks, such
   as management tracking of mail.  A popular use of reputation
   information is as input to a filtering engine that decides whether to
   deliver -- and possibly whether to specially mark -- a message.
   Filtering engines have become complex and sophisticated.  Their
   details are outside of DKIM's scope, other than the expectation that
   DKIM-related information is added to the varied soup of rules used by
   the engines.  The rules can cover signed messages and can deal with
   unsigned messages from a domain, if the domain has published
   information about is practices


8.  Security Considerations

   TBD


9.  IANA Considerations

   TBD




Hansen, et al.            Expires May 14, 2008                 [Page 17]

Internet-Draft            DKIM Service Overview            November 2007


10.  Acknowledgements

   TBD


11.  Informative References

   [I-D.ietf-openpgp-rfc2440bis]
              Callas, J., "OpenPGP Message Format",
              draft-ietf-openpgp-rfc2440bis-22 (work in progress),
              April 2007.

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status",
              draft-kucherawy-sender-auth-header-09 (work in progress),
              November 2007.

   [RFC0989]  Linn, J. and IAB Privacy Task Force, "Privacy enhancement
              for Internet electronic mail: Part I: Message encipherment
              and authentication procedures", RFC 989, February 1987.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1848]  Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
              Object Security Services", RFC 1848, October 1995.

   [RFC1991]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
              Exchange Formats", RFC 1991, August 1996.

   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

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

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",



Hansen, et al.            Expires May 14, 2008                 [Page 18]

Internet-Draft            DKIM Service Overview            November 2007


              RFC 3851, July 2004.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              May 2007.

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


Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: tony+dkimov@maillennium.att.com


   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   Email: dcrocker@bbiw.net


   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com













Hansen, et al.            Expires May 14, 2008                 [Page 19]

Internet-Draft            DKIM Service Overview            November 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hansen, et al.            Expires May 14, 2008                 [Page 20]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/