[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

DKIM Working Group                                             H. Santos
Internet-Draft                                 Santronics Software, Inc.
Intended status: Experimental                              July 26, 2006
Expires: January 27, 2007


              DKIM Signature Authorization Protocol (DSAP)
                       draft-santos-dkim-dsap-00

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 January 27, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   DSAP (DKIM Signature Authorization Protocol) is a DNS-based security
   protocol designed to complement the DKIM (DomainKeys Identified
   Message) protocol.  DSAP provides a simple to implement robust
   security wrapper around DKIM message signing practices by offering
   DKIM signature authorization controls.






Santos                  Expires January 27, 2007                [Page 1]


Internet-Draft                    DSAP                         July 2006


To be Done List

   1.  Continue to fine tune introduction, background, if required.
   2.  Complete usages text and examples TXT records for all DSAP
       Polices
   3.  Do we need the section 1.1 acroynms?
   4.  Simplify titles for DNS Policies sections.
   5.  Easier (combined) syntax for failure tags? f=a:value,s:value,x:
       value?
   6.  Complete the security section.


Table of Contents

   1.  Nomemclature and Definitions . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
     1.2.  Definitions and Acroynms . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Background: How did we get here? . . . . . . . . . . . . .  6
       2.1.1.  DKIM Protocol Overview . . . . . . . . . . . . . . . .  6
       2.1.2.  DKIM Security Issues . . . . . . . . . . . . . . . . .  7
       2.1.3.  DKIM Implementation Issues . . . . . . . . . . . . . .  8
   3.  Implementing DSAP  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Verifiers  . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Signers  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Mailing List Servers . . . . . . . . . . . . . . . . . . . 12
   4.  DSAP DNS Resource Record . . . . . . . . . . . . . . . . . . . 12
     4.1.  DSAP Tag: v=<dsap-version>/<dkim-version>  . . . . . . . . 13
     4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>; . . . 14
     4.3.  DSAP Tag; 3pl=<dom-list>;  . . . . . . . . . . . . . . . . 15
     4.4.  DSAP Tag: a=<hash-algorithm> . . . . . . . . . . . . . . . 15
     4.5.  DSAP Tag: r=<abuse-address>  . . . . . . . . . . . . . . . 16
     4.6.  DSAP Tag: n=<note> . . . . . . . . . . . . . . . . . . . . 16
     4.7.  DSAP Tag: t=y  . . . . . . . . . . . . . . . . . . . . . . 16
     4.8.  DSAP Tags: fa=<failure-handling>;
           fs=<failure-handling>; fx=<failure-handling>;  . . . . . . 16
     4.9.  Symbolic Semantics . . . . . . . . . . . . . . . . . . . . 17
   5.  DSAP Policies  . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  No Mail Expected . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  No Signature Expected  . . . . . . . . . . . . . . . . . . 18
     5.3.  Only 3rd party Signature Expected  . . . . . . . . . . . . 19
     5.4.  Only 3rd party Signature Expected, if any  . . . . . . . . 19
     5.5.  Only Original Party Signature Expected . . . . . . . . . . 19
     5.6.  Original and 3rd party Signatures Expected . . . . . . . . 20
     5.7.  Original Party Signature Expected, 3rd party Optional  . . 20
     5.8.  Only Original Party Signature Expected, if any . . . . . . 21
     5.9.  Original Party Optional, 3rd Party Signature Expected  . . 21
     5.10. Optional Original Party or 3rd Party Signatures  . . . . . 21



Santos                  Expires January 27, 2007                [Page 2]


Internet-Draft                    DSAP                         July 2006


   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
     7.1.  Policy Attacks . . . . . . . . . . . . . . . . . . . . . . 22
     7.2.  Multiple Original Addresses  . . . . . . . . . . . . . . . 22
     7.3.  Denial-of-Service Attacks  . . . . . . . . . . . . . . . . 22
     7.4.  Abuse Report Address Attacks . . . . . . . . . . . . . . . 22
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Appendix A.  DKIM-BASE Update Considerations . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24






































Santos                  Expires January 27, 2007                [Page 3]


Internet-Draft                    DSAP                         July 2006


1.  Nomemclature and Definitions

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Definitions and Acroynms

   MTA            Mail Transfer Agent.  Sender or Receiver of mail.
                  Generally viewed as a router within a MSA intra-
                  network where there is a inherent authentication.

   MUA            Mail User Agent.  Online or offline mail reader/writer
                  software.  Typically has its own MTA component for
                  sending mail.

   MSA            Mail Submission Agent.  Generally associated with a
                  MUA sending message to a ISP or ESP where there is an
                  authorized or authenticated association with the MUA.

   MDA            Mail Destination Agent.  Generally associated as the
                  final destination of the message where the message is
                  typically targeted for a local user.  If the MDA is
                  going to route the mail, then its behavioring more as
                  a MSA or MTA.

   MFA            Mail Filtering Agent.  Generally associated with a
                  post reception process which mayl analyze the payload
                  for local policy filtering requirements.

   MLS            Mailing List Server.  MLS may have a built-in MTA but
                  generally are standalone processes working in
                  conjunction with other MTA processes.

   SIGNATURE      In the context of this document, DKIM signatures are
                  the only signatures described.

   VALID          In the context of this document, a DKIM message which
                  has passed all verification test.

   INVALID        In the context of this document, a DKIM signed message
                  which has failed the verification process for one
                  reason or another.






Santos                  Expires January 27, 2007                [Page 4]


Internet-Draft                    DSAP                         July 2006


   TRANSACTION    The client/server transfer of an email message.

   SIGNER         A process or agent that adds a DKIM signature to a
                  message.

   VERIFIER       A process or agent that performs the DKIM message
                  verification.


2.  Introduction

   This document describes the DKIM Signature Authorization Protocol
   (DSAP) designed to provide signature authorization controls for the
   DKIM [DKIM-BASE] (Domain Keys Identified Message) core protocol.

   The object of DSAP is to provide the following added-value security
   to DKIM core protocol:

   o  Protect domain DKIM message signing practices,
   o  Protect domain reputations,
   o  Reduce DKIM verification overhead,
   o  Simplify DKIM implementation design considerations,
   o  Help increase DKIM acceptibility, and
   o  Help lower DKIM adoption barriers.

   DKIM is an electronic mail authentication protocol designed to
   strengthen the integrity of RFC 2822 [RFC2822] based message objects
   using a public-key cryptography and key server technology.  DKIM
   permits verification of the source and contents of messages by either
   Mail Destination Agents (MDAs), Mail Transfer Agents (MTAs) or Mail
   User Agents (MUAs).

   The objective of the DKIM framework is to permit a signing domain the
   ability to protect the message sender identity and the integrity of a
   message.  This process asserts a new reputation accountability for
   the domain responsible for the message.  Ultimately, the goal is to
   assist in the control of fraud, spam and phishing.

   Inherently, the DKIM core protocol is modeled around a "good citizen"
   or valid signature concept and does not attempt to place any meaning
   behind invalid or unverifable signatures, including how an invalid
   signature condition was met, leaving message classification to
   intentionally vague and undefined local policy decisions and as
   feedback to future augmented mail filtering systems.

   While this is an a worthy endeavor for the design and purity of a
   core protocol, this core model and its intentional vague DKIM
   protocol semantics leads to concerns with the unprotected nature of



Santos                  Expires January 27, 2007                [Page 5]


Internet-Draft                    DSAP                         July 2006


   message signing practice of DKIM implementations exposing the signing
   domains to exploitation, malicious abuse, and unauthorized usage.
   There are many engineering concerns with the stand-alone and
   unprotected usage of the DKIM protocol in a widely adopted network.

   A standalone DKIM core protocol implementation is unprotected for the
   following reasons:

   o  No protection against domain name exploitations,
   o  No foundation for consistent DKIM verification,
   o  Increases verification overhead, placing a high burden on
      verifiers,
   o  Provides little payoff (low efficiency),
   o  Hedges future on unknown, yet to be delivered, trusted-layers
      protocols (Reputation Services).

   To increase the acceptability of the DKIM protocol, it needs to offer
   value to all parties.  DSAP adds a simple to implement security layer
   around the unprotected core DKIM protocol.  When DSAP complimented
   with DKIM, DKIM will have less of a negative impact on domain
   reputations and verifiers and will make it easier for developers to
   add DKIM signing support.

   DSAP does not attempt to evaluate the reputation of the sender or
   client.  A good intention client can use DSAP as well as the bad
   intention client.  The main objective of DSAP is to establish a
   protocol consistency between all client types and to use the
   deviation from the consistency as part of a failure detection system.

2.1.  Background: How did we get here?

   For a complete functional and technical description of DKIM, please
   review the protocol specification described in DKIM [DKIM-BASE].

   This section will provide a basic overiew of the DKIM protocol, its
   security and implementation issues.

2.1.1.  DKIM Protocol Overview

   The DKIM core protocol allows an domain to take responsibility for a
   transportation of a message to a remote host receiver system.
   Although, the domain's reputation is now at stake when signing
   messages with the DKIM protocol, DKIM does not attempt to prescribe
   any specific actions for remote host receivers to take upon
   successful or unsuccessful validation of DKIM signed messages, nor
   does DKIM make any assertions about the behavior of the identity
   doing the signing.




Santos                  Expires January 27, 2007                [Page 6]


Internet-Draft                    DSAP                         July 2006


   Overall, the DKIM protocol design is primarily modeled on the basis
   of a "well behaved" market place.  Unfortunately, DKIM has little to
   no concerns about failure or error analysis leaving the repudiation
   process to future technology.

   This makes DKIM an unsafe and unprotected as a standalone protocol.

2.1.2.   DKIM Security Issues

   Implementing the DKIM verification protocol specification as
   described in DKIM [DKIM-BASE] leaves domain signature authorization
   insecured.  This is best shown in the following illustration:


                                                   DOMAIN USER
                                                       |
                                                       V
          +------------+      +-----------+      +-------------+
          |  RECEIVER  |<-----| TRANSPORT |<-----| DKIM SIGNER |
          +------------+      +-----------+      +-------------+
               |
               |
             -------
             PAYLOAD
             -------
               |
             __V____
            /       \                            +------------+
           / SIGNED  \---NO--------------------->| CONTINUE   |
           \ MESSAGE?/                           +------------+
            \_______/
               |
              YES
               |
               V                                 +--------------+
           +-----------+                         | CONTINUE/    |
           |           |------------------------>| CLASSIFY     |
           |           |  INVALID SIGNATURE      +--------------+
           | DKIM      |
           | SIGNATURE |
           | VERIFIER  |                         +--------------+
           |           |------------------------>| PASS         |
           |           |  VALID SIGNATURE        +--------------+
           +-----------+

                    Figure 1: DKIM Verification Outline

   As illustrated, a domain user submits a message which is signed by



Santos                  Expires January 27, 2007                [Page 7]


Internet-Draft                    DSAP                         July 2006


   the DKIM compliant domain administative unit.  The message is then
   transported to a DKIM compliant receiver where the payload is
   received and DKIM verification begins.  If the message is not signed,
   the transaction continues in its normal manner.  However, if a
   signature exist and the signatrure is valid, then the message is
   considered valid for passage.  If the signature is not valid, then
   the process continues as if the signature never existed.

   Implementing DKIM without some kind of signing authorization concept,
   opens the door to domain exploitations by not addressing the most
   obvious signing practices possible, such as:

   o  Does the domain ever distribute mail?
   o  Do you expect the mail to be unsigned?
   o  Do you expect to sign all mail?
   o  Is your domain the exclusive signer?
   o  Are 3rd party signers or signatures allowed?
   o  Are 3rd party signers allowed to strip your original signatures?

   These are basic fundamental signature authorization considerations
   that are lacking in the core DKIM protocol message signature
   methodology.

2.1.3.   DKIM Implementation Issues

   There are two sets of DKIM implementation issues which are
   complicated when there is no signature authorization controls:

   o  Complex DKIM signing methodology, and
   o  Low efficacy DKIM verification process.

   *Signing Messages*

   The DKIM signing methodology offers little control over the
   authorization of the signature process.  The presumption is that the
   sender has authorized to sign mail.  Domains have no control over who
   may sign mail.  This is particularily the case when there is
   involvement of 3rd party signers , such as Mailing List Servers.

   Most Mailing List Server (MLS) applications have practices of
   altering the message body content, including altering the message
   headers.  This practice will destroy the integrity of DKIM signed
   messages lowering the effectiveness of the DKIM protocol.

   *Signature Verification*

   The DKIM verification process, as illustrated in Figure 1.0
   (Figure 1), is modeled using the basic premise:



Santos                  Expires January 27, 2007                [Page 8]


Internet-Draft                    DSAP                         July 2006


   o  If not signed, continue.
   o  If signature is not valid, continue if never signed.

   The only case for reliability is when the DKIM signature is verified.
   However, even then, this valid signature may be done on a domain
   which did not authorize this signing process.


3.  Implementing DSAP

   The DKIM [DKIM-BASE] protocol has two complimentary components:

   1.  DKIM Signers
   2.  DKIM Verifier

   Signers add a DKIM signature to messages before and verifiers
   validate the DKIM signed messages.  Valid signatures provide an
   assertion of proving email authentication.

   DSAP may be integrated at the DKIM signer by the domain wishing to
   enhanced its security by exposing its message signing policy or
   practice, and at the DKIM verifier wishing to be consistent and honor
   a domain's signature authoration policies.

3.1.  Verifiers

   It is higly recommended DKIM implementations also implement DSAP in
   order to secure the unprotected nature of DKIM only operations.

   Where exactly DSAP is implementation in a mail framework is out of
   scope of this protocol.  However, in general, DSAP is likely to be
   implemented at the transport level or the post transaction level.



















Santos                  Expires January 27, 2007                [Page 9]


Internet-Draft                    DSAP                         July 2006


          +-----------+
          |  PAYLOAD  |
          +-----------+
               |
               v
        +----------------+
        |                |                            +------------+
        | DKIM           |--------------------------->| CONTINUE   |
        | Signature      | UNSIGNED: OPTIONAL         +------------+
        | Authorization  |
        | Protocol       |
        |                |                            +------------+
        |                |--------------------------->|            |
        |                | SIGNED: EXPIRED (1)        |            |
        |                |--------------------------->|            |
        |                | NO MAIL EXPECTED (4)       | FAILURE/   |
        |                |--------------------------->| CLASSIFY   |
        |                | UNSIGNED: REQUIRED (5)     |            |
        |                |--------------------------->|            |
        |                | SIGNED: NOT EXPECTED (6)   |            |
        |                |--------------------------->|            |
        |                | 3P SIGNED: NOT ALLOWED (7) |            |
        +----------------+                            +------------+
               |
               |
            SIGNED
            MESSAGE
               |
               v                                      +------------+
          +--------------+                            | CONTINUE/  |
          |              |--------------------------->| CLASSIFY   |
          |              |    INVALID SIGNATURE       +------------+
          | DKIM         |
          | SIGNATURE    |
          | VERIFICATION |                            +------------+
          | (8)          |--------------------------->| PASS       |
          |              |    VALID SIGNATURE         +------------+
          +--------------+

          Figure 2: DKIM Signature Authorization Protocol Outline

   The following steps MUST be followed by the DSAP compliant DKIM
   verifier once the PAYLOAD headers are available.  The sequential
   steps outlined provide conditions and criteria for negatively
   classifying a transaction:






Santos                  Expires January 27, 2007               [Page 10]


Internet-Draft                    DSAP                         July 2006


   1.  If a signature exist, check to see if the signature has expired
       (see DKIM [DKIM-BASE] expiration tag).  Signatures MUST NOT be
       considered valid if the current time is past the expiration date.

   2.  Extract the 2822.From: domain and perform a DSAP DNS query as
       defined in Section 4 to obtain the domain signature authorization
       policy.

   3.  For NXDOMAIN results and the message is signed, the transaction
       SHOULD be rejected.  A temporary negative response code, such as
       451, MAY be issued to address any domain DNS configuration
       delays.

   4.  If the op= and 3p= tags are missing or empty, no mail is expected
       from this domain.  The transaction SHOULD be rejected.

   5.  If the message is not signed, and a signature was expected
       (op=always or 3p=always), the transaction SHOULD be rejected.

   6.  If the message is signed, and no signature was expected (op=never
       and 3p=never), the transaction SHOULD be rejected.

   7.  If the message is signed by a 3rd party signer, and a 3rd party
       signer was not expected (3p=never), the transaction SHOULD be
       rejected.

   8.  If the message is signed, perform the DKIM verification process
       as defined in DKIM [DKIM-BASE] section 6.2.

3.2.  Signers

   Steps for DKIM signers supporting DSAP:

   1.  Define a DSAP DNS TXT record as described in Section 4.

   2.  Establish an original party and 3rd party signing policy which
       best suits the domain DKIM signing practice.  This includes the
       following considerations:

       *  Does the domain ever distribute mail?
       *  Do you expect the mail to be unsigned?
       *  Do you expect to sign all mail?
       *  Is your domain the exclusive signer?
       *  Are 3rd party signers allowed?
       *  Are 3rd party signers allowed to strip your original
          signatures?





Santos                  Expires January 27, 2007               [Page 11]


Internet-Draft                    DSAP                         July 2006


   3.  As described in DKIM [DKIM-BASE] Section 3.6, signature
       applications require some level of assurance that the
       verification public key is associated with the claimed signer.
       When signing hosted domain, routed, passthru or mailing list
       mail, check the originating domain's DSAP 3rd party resigning
       policy.  [[EDITOR-NOTE-MLS-RESIGNERS: Mailing List resigners need
       extra consideration here.  Originating domains should be aware of
       the risk associated with sending signed mail to a mailing list
       server.]]

   4.  If allowed to sign, follow DKIM [DKIM-BASE] to sign the message

3.3.  Mailing List Servers

   Mailing List Servers (MLS) applications who are compliant with DKIM
   and DSAP operations, SHOULD adhere to the following guidelines:

   Subscription Controls

      MLS subscription processes should perform a DSAP check to
      determine if a subscribing email domain DSAP policy is restrictive
      in regards to mail integrity changes or 3rd party signatures.  The
      MLS SHOULD only allow original domain policies who allow 3rd party
      signatures.

   Message Content Integrity Change

      List Servers which will alter the message content SHOULD only do
      so for original domains with optional DKIM signing practices and
      it should remove the original signature if present.  If the List
      Server is not going to alter the message, it SHOULD NOT remove the
      signature, if present.


4.  DSAP DNS Resource Record

   DSAP clients MUST perform TXT DNS queries based on domain part of the
   originating address, RFC2822.From header field, using the following
   DNS query question format:

      RR Type = TXT
      Domain = _dsap._domainkey.<domain>

   Where <domain> is the domain part of the originating address.

   If the domain is DSAP compliant, the resultant TXT record is a string
   containing semi-colon-delimited tags.  The current DSAP policy tags
   are defined in the following table:



Santos                  Expires January 27, 2007               [Page 12]


Internet-Draft                    DSAP                         July 2006


        +============================================================+
        | Description            |  DSAP Record Tag                  |
        |============================================================|
        | Version tag            |  v=<dsap-version>/<dkim-version>  |
        |------------------------------------------------------------|
        | Original party signing |  op=<signing-policy>              |
        | practice               |                                   |
        |------------------------------------------------------------|
        | 3rd party signing      |  3p=<signing-policy>              |
        | practice               |                                   |
        |------------------------------------------------------------|
        | Authorized List of     |  dl=<dom-list>                    |
        | 3rd party domains      |                                   |
        |------------------------------------------------------------|
        | Signature Hashing      |  a=<hash-algorithm>               |
        | Method                 |                                   |
        |------------------------------------------------------------|
        | Reporting address      |  r=<abuse-address>                |
        |------------------------------------------------------------|
        | Note or comment        |  n=<note>                         |
        |------------------------------------------------------------|
        | Testing flag           |  t=<testing-flag>                 |
        |------------------------------------------------------------|
        | Unauthorized signature |  fa=<failure-handling>            |
        | failure handling       |                                   |
        |------------------------------------------------------------|
        | Invalid Signature      |  fs=<failure-handling>            |
        | failure handling       |                                   |
        |------------------------------------------------------------|
        | Signature Expiration   |  fx=<failure-handling>            |
        | failure handling       |                                   |
        +------------------------------------------------------------+


                        DSAP DNS Record  Poicy Tags

4.1.  DSAP Tag: v=<dsap-version>/<dkim-version>

   This tag defines the current version number of the DSAP and DKIM
   implementation.

   For the current DSAP document draft level production, the values are:

   v=dsap1.0/dkim1







Santos                  Expires January 27, 2007               [Page 13]


Internet-Draft                    DSAP                         July 2006


4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

   From the viewpoint of the verifier, when a message is received, there
   are two basic pieces of signature information to be of interest when
   analyzing the transaction:

   o  Original Party Signatures (OP)

      *  never expected
      *  always expected
      *  optional

   o  3rd Party Signatures (3P)

      *  never expected
      *  always expected
      *  optional

   When the two signature types are combines, the possible policies are
   listed in this following table:

    +=================================================================+
    | op=         | 3p=        | Domain Policy Semantics              |
    |=================================================================|
    | empty       | empty      | No mail expected                     |
    |-----------------------------------------------------------------|
    | never       | never      | No signing expected                  |
    | never       | always     | Only 3P signing expected             |
    | never       | optional   | Only 3P signing optional             |
    |-----------------------------------------------------------------|
    | always      | never      | OP signature expected                |
    | always      | always     | Both parties expected                |
    | always      | optional   | OP expected, 3P may sign             |
    |-----------------------------------------------------------------|
    | optional    | never      | Only OP signing expected             |
    | optional    | always     | OP expected, 3P expected             |
    | optional    | optional   | Both parties may sign.               |
    +-----------------------------------------------------------------+

                  Figure 4: DSAP Message Signing Policies

   The goal here is to establish what the domain signature policy is and
   whether the domain allows 3rd party entities to resign the message
   independently or on behalf of original domain.

   Domains should define op= and 3p= policies which best defines their
   mail operations to best secure their mail transactions.  The policies
   are described in detail in Section 5.



Santos                  Expires January 27, 2007               [Page 14]


Internet-Draft                    DSAP                         July 2006


4.3.  DSAP Tag; 3pl=<dom-list>;

   The 3pl= is an optional tag that defines a list of 3rd party domains
   who are allowed to DKIM sign the message as a 3rd party signer.  This
   tag is ignored unless 3rd party signing policy is expected or
   optional (3p=always or 3p=optional).

   <dom-list> is a comma delimited list of domain names.

   Example:

   3pl=isp.com,outsource.com,mailinglist.com;

4.4.  DSAP Tag: a=<hash-algorithm>

   The a=<hash-algorithm> tag defines the possible signature hashing
   algorithms used by the domain DKIM message signer.  The a= tag is NOT
   optional.

   The current algorithms are defined in DKIM [DKIM-BASE] section 3.3.

   o  rsa-sha1
   o  rsa-sha256

   Example:

   a=rsa-sha1,rsa-sha256;

   The main purpose of the a= tag is to allow domain signers the design
   and implementation opportunity to determine the highest strength
   possible by a particular target verifier by looking the DSAP DNS
   record for the target recipient domain host.  If this query results
   with no a= tag information, the default should be rsa-sha1 is the
   highest strength possible.

   Essentially, this is a negotiation and backward compatibility
   concept.  It is quite possible earlier pre-standard DKIM
   implementations supporting only rsa-sha1 may still exist.  The domain
   DKIM message signer's desire is to achieve the highest protection
   possible.  Instead of signing mail with a particular algorithm and
   hoping for the best, the signer can predetermine what the receiving
   system can handle in terms of hashing strength.

   [[anchor17: This verifier lookup concept is best utilize for high-
   value domains in 1 to 1 transactions.  It would not be practice
   Mailing List resigners with large distributions to use this
   concept.]]




Santos                  Expires January 27, 2007               [Page 15]


Internet-Draft                    DSAP                         July 2006


4.5.  DSAP Tag: r=<abuse-address>

   This tag is optional.  If not defined, the default is no abuse-
   address is available.

   <abuse-address> is either the user-part or a FQDN email address to
   optional send abuse reports.

   Examples:
      r=abuse
      r=abuse@example.com

   If only the user-part is defined, then the full address is
   established by using the originating address domain.

   DKIM verifiers have the option to honor or not honor this reporting
   address.  DKIM signers MUST be aware this reporting address may not
   be utilized by verifers.

   Verifiers should be aware this reporting address can be a source of
   an report attack vector (Section 7.4).  One possible implementation
   considerations would to limit the report to one report only and to
   track the reception and/or response of the reporting.

4.6.  DSAP Tag: n=<note>

   The note tag (n=) is optional.  It allows a domain to store a human
   readable note or comment regarding the DSAP DNS record.  Its purpose
   is considered to be diagnostic in nature.

4.7.  DSAP Tag: t=y

   The t=y tag is optional.  If defined, the domain is currently testing
   DKIM.  Verifiers SHOULD NOT treat testers any different from
   production mode signers.  It SHOULD NOT be used as a way to bypass a
   failed signature classification policies.  However, verifiers SHOULD
   track testers for over extended usage of test signatures and MAY
   consider using the results to provide feedback to the domain.

4.8.  DSAP Tags: fa=<failure-handling>; fs=<failure-handling>;
      fx=<failure-handling>;

   The fa=, fs, and fx= tags define the domain preferred rejection
   action policy a verifier is recommended to perform when an
   unauthorized signature, failed signature or expired signature is
   detected, respectively.

   The fa= tag defines the handling for failed signature authorization.



Santos                  Expires January 27, 2007               [Page 16]


Internet-Draft                    DSAP                         July 2006


   The fs= tag defines the handling for failed signature verfication,
   and the fx= tag defines the handling when a signature expired or key
   is revoked.

   Failed signature include failures related to the DKIM-Signature
   hashing, syntax and encryption verification process.

   <failure-handling> values:

   FAIL                The verifer MUST reject the transaction when
                       failure is detected.  (Default)

   SOFTFAIL            The verifer SHOULD reject the transaction when
                       failure is detected.

   IGNORE              The verifer SHOULD NOT reject the transaction
                       when failure is detected.  This value may be
                       defined by the domain to signify the domain is
                       testing DKIM and failure may occur unexpectedly.
                       Verifiers SHOULD consider tracking this handler
                       value for abuse.

   The fa= and fs= tags are optional with default values of SOFTFAIL.

   Examples:

   fa=fail;fs=fail; fx=fail;  Domain has a MUST reject immediate policy
                       for unauthorized, failed or expired signatures.

   fa=fail;            Domain has a MUST reject immediate policy for
                       unauthorized signatures and a SHOULD reject
                       immediate policy for failed and expired
                       signatures.

   undefined tags;     DOMAIN has a SHOULD reject immediate policy for
                       all failures.

   fs=fail;  fx=fail;  Domain has a SHOULD reject immediate policy for
                       unauthorized signatures and a MUST reject
                       immediate policy for failed and expired
                       signatures.

4.9.  Symbolic Semantics

   There might be DNS capacity overhead concern with the expanded
   literal representation for the policies and fail handling tags.  To
   help address this, the following alias characters can be used for the
   literal values:



Santos                  Expires January 27, 2007               [Page 17]


Internet-Draft                    DSAP                         July 2006


   o  op= and 3p= signing policy values

         always (+)
         never (-)
         optional (~)

   o  fa=, fs=, and fx= failure-handling values

         fail (+)
         softfail (~)
         ignore (-)


5.  DSAP Policies

   Domains should define a DSAP policy which best describes their mail
   operations for DKIM signatures.  The following subsections list
   possible values and explain their use:

5.1.  No Mail Expected

   *Policy: op=; 3p=;*

   If this policy is defined, then no mail is expected from the original
   domain.  It is intent of the responsiible domain to not allow email
   domain to be use for any kind for mail transactions.  Verifiers
   SHOULD honor this domain policy request to negatively classify the
   message.

   Here is an example of a domain DNS TXT record No Mail Policy:

               _dsap._domainkey.example.com.  IN TXT
                     "v=dsap1.0; op=; 3p=; fa=fail;
                      n=We never send mail from this domain.
                      r=dkim-abuse@example.com;"


5.2.  No Signature Expected

   *Policy: op=never; 3p=never;*

   If this policy is defined, then a DKIM signature is not expected from
   any party.  If a DKIM signature is found in the message, verify or
   not, the verifier SHOULD honor the domain request to negatively
   classify the message.






Santos                  Expires January 27, 2007               [Page 18]


Internet-Draft                    DSAP                         July 2006


   Here is an example of a domain DNS TXT record Never Sign Policy:

          _dsap._domainkey.example.com.  IN TXT
                "v=dsap1.0; op=never; 3p=never; fa=fail;
                 n=We never sign messages, nor should anyone else.
                 r=dkim-abuse@example.com;"


5.3.  Only 3rd party Signature Expected

   *Policy: op=never; 3p=always;*

   If this policy is defined, then a DKIM signature MUST exist and it
   must be signed by a 3rd party.  If a DKIM signature is not found in
   the message, or an original party signature is found, the verifier
   SHOULD honor the domain policy request to negatively classify the
   message.  This policy maybe used in situations where domain owner
   never sends any email directly and always employs 3rd parties to send
   on its behalf and its known that all 3rd parties used are known to be
   sign messages.

   Here is an example of a domain DNS TXT record for this 3rd party only
   signing policy:

          _dsap._domainkey.example.com.  IN TXT
                "v=dsap1.0; op=never; 3p=always; fa=fail; fx=fail;
                 n=We never sign messages, nor should anyone else.
                 r=dkim-abuse@example.com;"


5.4.  Only 3rd party Signature Expected, if any

   *Policy: op=never; 3p=optional;*

   If this policy is defined, then a DKIM signature MAY exist and it
   must be signed by a 3rd party .  If an original partry DKIM signature
   is found, verify or not, the verifier SHOULD honor the domain request
   to negatively classify the message.

5.5.  Only Original Party Signature Expected

   *Policy: op=always; 3p=never;*

   If this policy is defined, then a DKIM signature MUST exist and it
   must be signed by the original domain only.  If no signature is found
   or a 3rd party signature is found, the verifier SHOULD honor the
   domain policy request to negatively classify the message.




Santos                  Expires January 27, 2007               [Page 19]


Internet-Draft                    DSAP                         July 2006


   This policy is considered to be an exclusive signing practice by the
   original domain only and is expected to be used by organizations that
   never send any email to mail lists or through 3rd parties and always
   expect to communicate directly with recipient.  Such organizations
   are those providing data of very sensitive nature (such as personal
   financial information) and using strong internal security policies.
   These organizations are often highly concerned about inappropriate
   and fraudulent uses of their domain (such as cases of "phishing") and
   want to make sure that only emails directly from their system are
   accepted as valid by recipient.

   Here is an example of such policy record used by an imaginary Bank
   with domain bank.example.  Please note tags are separate per line for
   illustrative purposes only:

   _dsap._domainkey.bank.example.  IN TXT
         "v=dsap1.0; a=rsa-sha256; op=always; 3p=never;
          n=We only send DKIM signed email, do not trust anything else
            such as notices allegedly from security@bank.example. Please
            report all such abuse to;
          r=phishing-reports@bank.example;"


   Note: The above comment in "n" tag is very long and given only to
   help illustrate this example.  Whenever possible shorter text should
   be used in DSAP records.

5.6.  Original and 3rd party Signatures Expected

   *Policy: op=always; 3p=always; *

   If this policy is defined, then two or more DKIM signatures
   signatures are expected to exist in the message.  The first one is
   the original party signature, and the subsequent signatues are 3rd
   party signatures.  If no signatures are found or either the original
   or 3rd party signatures are missing, verify or not, the verifier
   SHOULD honor the domain request to negatively classify the message.

5.7.  Original Party Signature Expected, 3rd party Optional

   *Policy: op=always; 3p=optional; *

   If this policy is defined, then one or more DKIM signatures
   signatures are expected to exist in the message.  The first one is a
   required original party signature, and any subsequent signatures are
   3rd party signatures.  If no signatures are found or the original
   party signature does not exist, verify or not, the verifier SHOULD
   honor the domain policy request to negatively classify the message.



Santos                  Expires January 27, 2007               [Page 20]


Internet-Draft                    DSAP                         July 2006


5.8.  Only Original Party Signature Expected, if any

   *Policy: op=optional; 3p=never; *

   If this policy is defined, then only an original party DKIM signature
   may exist.  If a 3rd party signature is found, verify or not, the
   verifier SHOULD honor the domain policy request to negatively
   classify the message.

   Mailing List Servers MAY strip the signature from the message for
   list distribution.

   [[anchor31: The idea is if a domain optional signs a messages for a
   mailing list submission, should the LS be allowed to removed.  If the
   OA signature was required. the LS should not remove it.  However, if
   a optional policy is used, then veriifers will survive any LS mail
   integrity changes as long as the OA signature is removed.]]

5.9.  Original Party Optional, 3rd Party Signature Expected

   *Policy: op=optional; 3p=always;*

   If this policy is defined, then one or more DKIM signatures
   signatures are expected to exist in the message.  The first one is
   the original party signature and it is optional.  Only the 3rd party
   signature is expected to exist.  If no signatures are found or the
   3rd party signature is missing, verify or not, the verifier SHOULD
   honor the domain request to negatively classify the message.

   Since List Servers must sign the message, it SHOULD strip the
   original party signature from the message for list distribution if
   the mail integrity has changed.

   [[anchor33: Why would a domain use this 3PS must sign policy?]]

5.10.  Optional Original Party or 3rd Party Signatures

   *Policy: op=optional; 3p=optional;*

   If this policy is defined, then one or more DKIM signatures
   signatures may exist in the message.  The original or 3rd party
   signatures are optional.  The first one is the original party
   signature, and any subsequent signatures are 3rd party signatures.
   If no signatures are found, the verifier SHOULD honor the domain
   request to positively classify the message.

   List Servers MAY strip the original party signature from the message
   for list distribution.



Santos                  Expires January 27, 2007               [Page 21]


Internet-Draft                    DSAP                         July 2006


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

7.1.  Policy Attacks

   Policy attacks are those when a bad actor is sending mail using an
   originating address that is highly restrictive with the sole purpose
   to stop the delivery of mail.

7.2.  Multiple Original Addresses

   TBD

7.3.  Denial-of-Service Attacks

   TBD

7.4.  Abuse Report Address Attacks

   TBD


8.  Acknowledgements

   Discussions related to siganture policies in the IETF-DKIM Working
   Group among many participants lead to the development of this
   proposed draft.  There are a few contributors who wish to remain
   anonymous who provided rich guidance and editorial input.  Mr. Santos
   extends his appreciation for their contributions to the proposal.


9.  References

9.1.  Normative References

   [DKIM-BASE]
              Allman, E., "DomainKeys Identified Mail Signatures",
              April 2006, <http://mipassoc.org/dkim/specs/
              draft-allman-dkim-base-01.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Santos                  Expires January 27, 2007               [Page 22]


Internet-Draft                    DSAP                         July 2006


              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

9.2.  Informative References


Appendix A.  DKIM-BASE Update Considerations

   In an effort to offer upward compatibility for current DKIM BASE
   implementation who may wish to expose their desire to support DSAP,
   the following key record TXT tag is defined:

   dsap=1;

   If this tag is defined in the _domainkey.<domain> TXT record, the
   verifier SHOULD consider honoring the domain's desire to better
   secure its DKIM mail signing practice.

   SInce DKIM-BASE only implementations will lookup the key record
   first, the inclusion of the dsap=1 tag could server as a tracked or
   traced item during verification.  Verifiers would then be able to
   review their implementation for enhancing domain DKIM signature
   authorization security by incorporating DSAP.


Author's Address

   Hector Santos
   Santronics Software, Inc.
   15600 SW 158 ST Suite #306
   Homestead, Florida, FL  33033
   United States of America

   Email: hsantos@isdg.net
   URI:   http://www.isdg.net











Santos                  Expires January 27, 2007               [Page 23]


Internet-Draft                    DSAP                         July 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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).





Santos                  Expires January 27, 2007               [Page 24]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/