Internet DRAFT - draft-santos-dkim-dsap
draft-santos-dkim-dsap
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]
