TOC 
Individual SubmissionE. Allman
Internet-DraftSendmail, Inc.
Intended status: Standards TrackM. Delany
Expires: March 3, 2007Yahoo! Inc.
 J. Fenton
 Cisco Systems, Inc.
 August 30, 2006


DKIM Sender Signing Practices
draft-allman-dkim-ssp-02

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 March 3, 2007.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.).

This document describes the records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results.

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

(Unresolved Issues/To Be Done)

Security Considerations needs further work.

Need to check existing ABNF.

Text structure of document needs to be examined; this is a quick slash-and-burn approach.



Table of Contents

1.  Introduction
2.  Language and Terminology
    2.1.  Terms Imported from DKIM-Base
    2.2.  Valid Signature
    2.3.  Originator Address
    2.4.  Alleged Signer
    2.5.  Alleged Originator
    2.6.  Sender Signing Practices
    2.7.  Originator Signature
    2.8.  Suspicious
    2.9.  Third-Party Signature
    2.10.  Verifier Acceptable Third-Party Signature
3.  Operation Overview
4.  Detailed Description
    4.1.  DNS Representation
    4.2.  Record Syntax
    4.3.  Sender Signing Practices Check Procedure
5.  Third-Party Signatures and Mailing Lists
    5.1.  Mailing List Manager Actions
    5.2.  Signer Actions
6.  IANA Considerations
7.  Security Considerations
    7.1.  Fraudulent Sender Address
    7.2.  DNS Attacks
8.  References
    8.1.  Normative References
    8.2.  Informational References
Appendix A.  Change Log
    A.1.  Changes since -01
    A.2.  Changes since -00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer’s domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

However, the legacy of the Internet is such that not all messages will be signed, and the absence of a signature on a message is not an a priori indication of forgery. In fact, during early phases of deployment it must be expected that most messages will remain unsigned. However, some domains may choose to sign all of their outgoing mail, for example, to protect their brand name. It is highly desirable for such domains to be able to advertise that fact to verifiers, and that messages claiming to be from them that do not have a valid signature are likely to be forgeries. This is the topic for sender signing practices.

In the absence of a valid DKIM signature on behalf of the "From" address [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.), the verifier of a message MUST determine whether messages from that sender are expected to be signed, and what signatures are acceptable. In particular, whether a domain signs all outbound email must be communicated to the verifier. Without such a mechanism, the benefit of message signing techniques such as DKIM is limited since unsigned messages will always need to be considered to be potentially legitimate. This determination is referred to as a Sender Signing Practices check.

Sender Signing Practices MAY be expressed on behalf of an entity which may be a domain or an individual address. Expression of signing practices on behalf of individual addresses will, of course, entail additional transaction load.

Conceivably, such expressions might be imagined to be extended in the future to include information about what hashing algorithms a domain uses, what kind of messages might be sent (e.g., bulk vs. personal vs. transactional), etc. Such concerns are out of scope of this standard, because they can be expressed in the key record ("Selector") with which the signature is verified. Expressions of signing practice which require outside auditing are out of scope for this specification because they fall under the purview of reputation and accreditation.

This document refers extensively to [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.), which should be read as a prerequisite to this document.



 TOC 

2.  Language and Terminology



 TOC 

2.1.  Terms Imported from DKIM-Base

Some terminology used herein is derived directly from [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.). Briefly,

• A "Signer" is the agent that signs a message. In many cases it will correspond closely with the original author of the message or an agent working on the author’s behalf.

• A "Verifier" is the agent that verifies a message by checking the actual signature against the message itself and the public key published by the alleged signer. The Verifier also looks up the Sender Signing Practices published by the domain of the Originator Address if the message is not correctly signed by the Alleged Originator.

• A "Selector" specifies which of the keys published by a signing domain should be queried. It is essentially a way of subdividing the address space to allow a single sending domain to publish multiple keys.



 TOC 

2.2.  Valid Signature

A "Valid Signature" is any signature on a message which correctly verifies using the procedure described in section 6.1 of [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.).



 TOC 

2.3.  Originator Address

The "Originator Address" is the email address in the From header field of a message [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.), or if and only if the From header field contains multiple addresses, the first address in the From header field.

NON-NORMATIVE RATIONALE: The alternative option when there are multiple addresses in the From header field is to use the value of the Sender header field. This would be closer to the semantics indicated in [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) than using the first address in the From header field. However, the large number of deployed Mail User Agents that do not display the Sender header field value argues against that. Multiple addresses in the From header field are rare in real life.



 TOC 

2.4.  Alleged Signer

An "Alleged Signer" is the identity of the signer claimed in the DKIM-Signature header field in a message received by a Verifier; it is "alleged" because it has not yet been verified.



 TOC 

2.5.  Alleged Originator

An "Alleged Originator" is the Originator Address of a message received by a Verifier; it is "alleged" because it has not yet been verified.



 TOC 

2.6.  Sender Signing Practices

"Sender Signing Practices" (or just "practices") consist of a machine-readable record published by the domain of the Alleged Originator which includes information about whether or not that entity signs all of their email, and whether signatures from third parties are sanctioned by the Alleged Originator.



 TOC 

2.7.  Originator Signature

An "Originator Signature" is any Valid Signature where the signing address (listed in the "i=" tag if present, otherwise the null address, representing an unknown user, followed by "@", followed by the value of the "d=" tag) matches the address in the "From" header field. If the signing address does not include a local-part, then only the domains must match; otherwise, the two addresses must be identical.



 TOC 

2.8.  Suspicious

Messages that do not contain a valid Originator Signature and which are inconsistent with a Sender Signing Practices check (e.g., are received without a Valid Signature and the sender's signing practices indicate all messages from the entity are signed) are referred to as "Suspicious". The handling of such messages is at the discretion of the Verifier or final recipient. "Suspicious" applies only to the DKIM layer; a Verifier may decide the message should be accepted on the basis of other information beyond the scope of this document. Conversely, messages deemed non-Suspicious may be rejected for other reasons.



 TOC 

2.9.  Third-Party Signature

A "Third-Party Signature" is a Valid Signature which is not an Originator Signature.



 TOC 

2.10.  Verifier Acceptable Third-Party Signature

A Verifier Acceptable Third-Party Signature is a Third-Party Signature that the Verifier is willing to accept as meaningful for the message under consideration. The Verifier may use any criteria it deems appropriate for making this determination.



 TOC 

3.  Operation Overview

Sender Signing Practices checks MUST be based on the Originator Address. If the message contains a valid Originator Signature, no Sender Signing Practices check need be performed: the Verifier SHOULD NOT look up the Sender Signing Practices and the message SHOULD be considered non-Suspicious.

Verifiers checking messages that do not have at least one valid Originator Signature MUST perform a Sender Signing Practices check on the domain specified by the Originator Address as described in Section 4.3 (Sender Signing Practices Check Procedure).

The result of a Sender Signing Practices check is one of five possible practices:

(1) Some messages from this entity are not signed; the message SHOULD be presumed to be legitimate in the absence of a valid signature. This is the default.

(2) All messages from this entity are signed; all messages from this entity SHOULD have a Valid Signature, either directly on behalf of the originator or on behalf of a third party (e.g., a mailing list or an outsourcing house) handling the message.

(3) All valid messages from this entity are signed, and SHOULD have a Valid Signature from this entity. Third-Party Signatures SHOULD not be accepted.

(4) Signing practices for this domain are expressed at the individual address level. A second Sender Signing Practices check MUST be performed specifying the individual address.

(5) The domain does not exist.

If a message is encountered by a Verifier without a valid Originator Signature, the results MUST be interpreted as follows:

If the result of the check is practice (1) described above, the message MUST be considered non-Suspicious.

If the result of the check is practice (2), and any verifiable signature is present from some signer other than the Originator Address in the message, the message SHOULD be considered non-Suspicious.

If the result of the check is practice (3) or (5), the message MUST be considered Suspicious.

If the result of the check is practice (4), a second Sender Signing Practices check SHOULD be performed based on the entire Originator Address and interpreted using the above steps. If no signing practices are published at the user level, the signing practices of the domain should be used instead and interpreted as described above.

If the Sender Signing Practices record for the domain does not exist but the domain does exist, Verifier systems MUST assume that some messages from this entity are not signed and the message SHOULD NOT be considered to be Suspicious.



 TOC 

4.  Detailed Description



 TOC 

4.1.  DNS Representation

Sender Signing Practices records are published using the "DKIMP" DNS resource record type. The numeric record type for DKIMP is [[TBD]].

The RDATA for DKIMP resource records is textual in format, like that of TXT records but with specific syntax and semantics relating to their role in describing sender signing practices. The "Tag=Value List" syntax described in section 3.2 of [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.) is used. Records not in compliance with that syntax or the syntax of individual tags described in Section 4.2 (Record Syntax) MUST be ignored (considered equivalent to a NODATA result) for purposes of message disposition, although they MAY cause the logging of warning messages via an appropriate system logging mechanism.

SSP records for a domain are published at the domain's location (e.g., example.com) in the DNS hierarchy. SSP records for individual addresses are published at "<user>._user.<domain>" (e.g., jdoe._user.example.com), with any characters not permitted in DNS labels removed and with the resulting label truncated, if necessary, at 63 characters per section 2.3.1 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.).

NON-NORMATIVE RATIONALE: Use of a separate resource record allows the Verifier to determine whether the domain exists in addition to the existence of an SSP record with a single query. Use of the "_user" separator in the user-level query prevents the publication of practices for the subdomain jdoe.example.com from conflicting with user-level practices for <jdoe@example.com>.

Since the Domain Name System returns a NODATA, rather than an NXDOMAIN (nonexistent domain) response for any record, such as a hostname, for which there is a record of any resource record type, a query for the signing practices of such a name would indicate that there are no signing practices for the address, which might be undesirable. Conversely, the burden of publishing SSP records for all such names could be considerable.

To address this problem, when a domain-level SSP query returns a NODATA response, the Verifier MUST repeat the query to the next higher level of the domain hierarchy unless the query is already at the top-level. This allows hostnames and other identifiers that may be used in Originator Addresses to inherit the signing practices of their parent domain. Bona fide subdomains SHOULD publish separate SSP records; otherwise, hostnames and other identifiers in subdomains will result in the Verifier not finding the SSP record.



 TOC 

4.2.  Record Syntax

Signing practices records follow the tag-value syntax described in section 3.2 of [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.). Tags used in SSP records are as follows. Unrecognized tags and tags with illegal values MUST be ignored. In the ABNF below, the FWS token is inherited from [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) with the exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).

p=
Outbound signing practices for the entity (plain-text; OPTIONAL, default is "unknown"). Possible values are as follows:
unknown
The entity may sign some or all email.
all
All mail from the entity is signed; unsigned email MUST be considered Suspicious. The entity may send messages through agents that may modify and re-sign messages, so email signed with a Verifier Acceptable Third-Party Signature SHOULD be considered non-Suspicious.
strict
All mail from the entity is signed; messages lacking a valid Originator Signature MUST be considered Suspicious. The entity does not expect to send messages through agents that may modify and re-sign messages.
NON-NORMATIVE RATIONALE: Strict practices may be used by entities which send only transactional email to individual addresses and which are willing to accept the consequence of having some mail which is re-signed appear suspicious in return for additional control over their addresses. Strict practices may also be used by entities which do not send (and therefore do not sign) any email.
ABNF:
ssp-p-tag     = %x70 [FWS] "=" [FWS] "unknown" / "all" / "strict"
u=
User-level signing practices for the entity (plain-text; OPTIONAL, default is "no"). This tag MUST NOT be present in user-level SSP records. Possible values are as follows:
yes
Repeat query at user level. The Verifier MUST look up the user-level Signing Practices by querying for a DKIMP record at "<user>._user.<domain>" where <user> is the local-part of the Originator Address (i.e., the portion of the address before the "@" character) with any characters not permitted in DNS labels removed and with the resulting label truncated, if necessary, at 63 characters per section 2.3.1 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) and <domain> is the domain-part of the Originator Address (i.e., the portion of the address after the "@" character). If no user-level SSP record is found (either a NODATA or NXDOMAIN response is received), the practices described in this record should be used.
no
Do not repeat the query at user level; use the practices described in this record.
ABNF:
ssp-u-tag     = %x75 [FWS] "=" [FWS] "yes" / "no"
t=
Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is that no flags are set). Flag values are:
y
The entity is testing signing practices, and the Verifier SHOULD NOT consider a message suspicious based on the record.
s
The signing practices apply only to the named domain, and not to subdomains.
ABNF:
ssp-t-tag     = %x75 [FWS] "=" [FWS] ssp-t-tag-flag
                        0*( [FWS] ":" [FWS] ssp-t-tag-flag )
ssp-t-tag-flag = "y" / "s" / hyphenated-word ; for future extension
hyphenated-word =  ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
Unrecognized flags MUST be ignored.


 TOC 

4.3.  Sender Signing Practices Check Procedure

The Sender Signing Practices check SHOULD be performed after DKIM signature(s), including any where the Alleged Signer is the Alleged Originator, have been verified. Verifiers MUST produce a result that is semantically equivalent to applying the following steps in the order listed. In practice, several of these steps can be performed in parallel in order to improve performance.

  1. If a valid Originator Signature exists, the message is non-Suspicious, and the algorithm terminates.
  2. The Verifier MUST query DNS for a DKIMP record corresponding to the domain part of the Originator Address. If the result of this query is a NODATA response, proceed to step 10. If the result of this query is a NXDOMAIN response, the message is Suspicious and the algorithm terminates. Otherwise, proceed to the following steps using the record retrieved by the query.
  3. If the SSP "t" tag exists and any of the flags is "y" (indicating testing), the message is non-Suspicious and the algorithm terminates.
  4. If the SSP "u" tag exists and the value is "yes", retain the value of the "p" tag; otherwise proceed to step 7.
  5. The Verifier MUST query DNS for a user-level DKIMP record at the location defined in Section 4.1 (DNS Representation). If the result of this query is a NODATA or NXDOMAIN response, then a user-level SSP record was not found; go to step 7 and proceed using the retained value of the "p" tag from the domain-level practices.
  6. Proceed using the value of the "p" tag from the user-level query.
  7. If the value of the SSP "p" tag is "unknown", the message is non-Suspicious and the algorithm terminates.
  8. If the value of the SSP "p" tag is "all", and one or more Valid Signatures are present on the message, the message is Not Suspicious and the algorithm terminates.
  9. The message is Suspicious and the algorithm terminates.
  10. (check for parent domain policy) If the domain of the Originator Address is a top-level domain (e.g., a country code), then an SSP record was not found and the message is Not Suspicious.
  11. The Verifier MUST query DNS for a DKIMP record corresponding to the immediate parent of the Originator Address. If the result of this query is a NODATA response, then an SSP record was not found and the message is non-Suspicious.
  12. If the SSP "t" tag exists and any of the flags is "y" (indicating testing) or "s" (indicating that the record should not be used apply to a subdomain), the message is non-Suspicious and the algorithm terminates. Otherwise proceed to step 4.


 TOC 

5.  Third-Party Signatures and Mailing Lists

There are several forms of mailing lists, which interact with signing in different ways.

The first two cases act in obvious ways and do not require further discussion. However, the third case is problematic. The remainder of this session applies only to that case.



 TOC 

5.1.  Mailing List Manager Actions

Mailing List Managers should make every effort to ensure that messages that they relay and which have Valid Signatures upon receipt also have Valid Signatures upon retransmission. In particular, Mailing List Managers that modify the message in ways that break existing signatures SHOULD:

Mailing List Managers MAY:



 TOC 

5.2.  Signer Actions

All Signers SHOULD:

Signers wishing to avoid the use of Third-Party Signatures SHOULD do everything listed above, and also:



 TOC 

6.  IANA Considerations

Use of the _user prefix in DKIMP DNS records will require registration by IANA.

The DKIMP RR type must be registered by IANA.



 TOC 

7.  Security Considerations

Security considerations in the Sender Signing Practices are mostly related to attempts on the part of malicious senders to represent themselves as other senders, often in an attempt to defraud either the recipient or the Alleged Originator.



 TOC 

7.1.  Fraudulent Sender Address

[[Assuming 3rd party signature is based on Sender header field]] If the Sender Signing Practices sanction third-party signing, an attacker can create a message with a From header field of an arbitrary sender and a legitimately signed Sender header field



 TOC 

7.2.  DNS Attacks

An attacker might attack the DNS infrastructure in an attempt to impersonate SSP records. However, such an attacker is more likely to attack at a higher level, e.g., redirecting A or MX record lookups in order to capture traffic that was legitimately intended for the target domain. Domains concerned about this should use DNSSEC (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4033].



 TOC 

8.  References



 TOC 

8.1. Normative References

[I-D.ietf-dkim-base] Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” draft-ietf-dkim-base-05 (work in progress), August 2006.
[RFC1035] Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2822] Resnick, P., “Internet Message Format,” RFC 2822, April 2001.
[RFC4234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005 (TXT, HTML, XML).


 TOC 

8.2. Informational References

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005.


 TOC 

Appendix A.  Change Log



 TOC 

A.1.  Changes since -01



 TOC 

A.2.  Changes since -00

From a "diff" perspective, the changes are extensive. Semantically, the changes are:



 TOC 

Authors' Addresses

  Eric Allman
  Sendmail, Inc.
  6425 Christie Ave, Suite 400
  Emeryville, CA 94608
  USA
Phone:  +1 510 594 5501
Email:  eric+dkim@sendmail.org
URI: 
  
  Mark Delany
  Yahoo! Inc.
  701 First Avenue
  Sunnyvale, CA 94089
  USA
Phone:  +1 408 349 6831
Email:  markd+dkim@yahoo-inc.com
URI: 
  
  Jim Fenton
  Cisco Systems, Inc.
  MS SJ-9/2
  170 W. Tasman Drive
  San Jose, CA 95134-1706
  USA
Phone:  +1 408 526 5914
Email:  fenton@cisco.com
URI: 


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment