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

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 October 28, 2006.

Copyright Notice

Copyright © 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. DSAP provides a consistent protocol foundation support for required electronic mail software DKIM designs.

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.

Table of Contents

1.  Nomemclature and Definitions
    1.1.  Requirements Language
    1.2.  Definitions and Acroynms
2.  Introduction
    2.1.  Background: How did we get here?
        2.1.1.  DKIM Protocol Overview
        2.1.2.  DKIM Security Issues
        2.1.3.  DKIM Implementation Issues
3.  Implementing DSAP
    3.1.  Verifiers
    3.2.  Signers
    3.3.  Mailing List Servers
4.  DSAP DNS Resource Record
    4.1.  DSAP Tag: v=<dsap-version>/<dkim-version>
    4.2.  DSAP Tag: op=<signing-policy>; 3p=<signing-polucy>;
    4.3.  DSAP Tag; dl=<dom-list>;
    4.4.  DSAP Tag: a=<hash-algorithm>
    4.5.  DSAP Tag: r=<abuse-address>
    4.6.  DSAP Tag: n=<note>
    4.7.  DSAP Tag: t=y
    4.8.  DSAP Tags: fa=<failure-handling>; fs=<failure-handling>; fx=<failure-handling>;
    4.9.  Symbolic Semantics
5.  DSAP Policies
    5.1.  No Mail Expected
    5.2.  No Signature Expected
    5.3.  Only 3rd party Signature Expected
    5.4.  Only 3rd party Signature Expected, if any
    5.5.  Only Original Party Signature Expected
    5.6.  Original and 3rd party Signatures Expected
    5.7.  Original Party Signature Expected, 3rd party Optional
    5.8.  Only Original Party Signature Expected, if any
    5.9.  Original Party Optional, 3rd Party Signature Expected
    5.10.  Optional Original Party or 3rd Party Signatures
6.  IANA Considerations
7.  Security Considerations
    7.1.  Policy Attacks
    7.2.  Multiple Original Addresses
    7.3.  Denial-of-Service Attacks
    7.4.  Abuse Report Address Attacks
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  DKIM-BASE Update Considerations
§  Author's Address
§  Intellectual Property and Copyright Statements

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.

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.

TRANSACTION

The client/server transfer of an email message.

SIGNER

A process that adds a DKIM signature to a messages.

VERIFIER

A process 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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [DKIM‑BASE] (Domain Keys Identified Message) core protocol.

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

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

DKIM is an electronic mail authentication protocol designed to strengthen the integrity of RFC 2822 (Resnick, P., “Internet Message Format,” April 2001.) [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 domain 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 unveriable 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 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:

• No protection against domain name exploitations,
• No foundation for consistent DKIM verification,
• Increases verification overhead, placing a high burden on verifiers,
• Provides little payoff (low efficiency),
• 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. DSAP should be a fundamental natural part of DKIM protocol. If implemented, DKIM will have less of a negative impact on domain reputations and verifiers, and also makes 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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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.

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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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        +--------------+
 +-----------+

As illustrated, a domain user submits a message which is signed by 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:

• 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 or signatures allowed?
• 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:

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

2.1.3.1.  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 involved 3rd party signers, i.e. 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.

2.1.3.2.  Signature Verification

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

• If not signed, continue.
• 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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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 can be implemented at the transport level or the post transaction level.

  +-----------+
  |  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 |
  | VERIFIER  |                               +------------+
  | (8)       |------------------------------>| PASS       |
  |           |      VALID SIGNATURE          +------------+
  +-----------+

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:

1. If a signature exist, check to see if the signature has expired (see DKIM (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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 (DSAP DNS Resource Record) 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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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 (DSAP DNS Resource Record).
   
   
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?
     
     
3. As described in DKIM (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [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 striing containing semi-colon-delimited tags. The current DSAP policy tags are defined in the following table:

  +============================================================+
  | 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       |                                   |
  +------------------------------------------------------------+

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=dsap0.0/dkim1

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

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:

• Original Party Signatures (OP)
  
  
  • never expected
  • always expected
  • optional
    
    
• 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.               |
+-----------------------------------------------------------------+

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 the original domains behalf.

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

4.3.  DSAP Tag; dl=<dom-list>;

The dl= tag defines a list of 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:

dl=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 (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [DKIM‑BASE] section 3.3.

• rsa-sha1
• 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.

[anchor19] (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.)

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

This tag is optional. If not define, 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 (Abuse Report Address Attacks). 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. 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 includes failured 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 MAY 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. However, this handler should not be tolerated by verifiers and should be tracked 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 MAY be used for the literal values:

• op= and 3p= signing policy values
  
  

  always (+)

  never (-)

  optional (~)
  
  

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

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:

_policy._domainkey.example.com.  IN TXT
      "v=dsap1.1; 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.

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

_policy._domainkey.example.com.  IN TXT
      "v=dsap1.1; 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:

_policy._domainkey.example.com.  IN TXT
      "v=dsap1.1; 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.

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:

_policy._domainkey.bank.example.  IN TXT
      "v=dsap1.1; 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.

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.

[anchor33] (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.

[anchor35] (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.

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

7.3.  Denial-of-Service Attacks

7.4.  Abuse Report Address Attacks

8.  Acknowledgements

The following individuals contributed input and guidance in the production of this proposal and document: Tony Hansen, Stephen Farrel, Bill Oxley.

9.  References

9.1. Normative References

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

Full Copyright Statement

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