|Network Working Group||E. Allman|
|Internet Draft||Sendmail, Inc.|
|Intended status: Standards Track||Yahoo! Inc.|
|Expires: December 2007||J. Fenton|
|Cisco Systems, Inc.|
DKIM Sender Signing Practices
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 in December 2007.
Copyright © The IETF Trust (2007). All Rights Reserved.
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 [RFC4871].
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.
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].
Security Considerations needs further work.
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], 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.
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. In contrast, this specification focuses on information which is relevant in the absence of a valid signature. Expressions of signing practice which require outside auditing are similarly out of scope for this specification because they fall under the purview of reputation and accreditation.
The detailed requirements for Sender Signing Practices are given in [I-D.ietf-dkim-ssp-requirements], which the protocol described in this document attempts to satisfy. This document refers extensively to [RFC4871], which should be read as a prerequisite to this document.
Some terminology used herein is derived directly from [RFC4871]. Briefly,
A "Valid Signature" is any signature on a message which correctly verifies using the procedure described in section 6.1 of [RFC4871].
The "Originator Address" is the email address in the From header field of a message [RFC2822], or if and only if the From header field contains multiple addresses, the first address in the From header field.<list>
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] 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.
An "Alleged Signer" is the identity of the signer claimed in a DKIM-Signature header field in a message received by a Verifier; it is "alleged" because it has not yet been verified.
An "Alleged Originator" is the Originator Address of a message received by a Verifier; it is "alleged" because it has not yet been verified.
"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.
An "Originator Signature" is any Valid Signature where the signing address (listed in the "i=" tag if present, otherwise its default value, consisting of 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.
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 evaluation of the message; 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.
A "Third-Party Signature" is a Valid Signature which is not an Originator 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.
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.4.
The result of a Sender Signing Practices check is one of four possible practices:
If a message is encountered by a Verifier without a valid Originator Signature, the results MUST be interpreted as follows:
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.
Sender Signing Practices records are published using the DNS TXT resource record type.
The RDATA for SSP resource records is textual in format, 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 [RFC4871] is used. Records not in compliance with that syntax or the syntax of individual tags described in Section 4.3 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 a location in the domain's DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for example.com would be a TXT record whcih is published at _ssp._domainkey.example.com.
Sender Signing Policy is intended to apply to all mail allegedly sent from a given Originating Domain, and to the greatest extent possible, to all subdomains of that domain. There are several cases that need to be considered in that regard:
In all of these cases, the records may be published either in separate DNS zones or as records within a parent zone.
Normally, a domain expressing Sender Signing Practices will want to do so for both itself and its all of its "descendents" (child domains, and hosts, at all lower levels). Domains wishing to do so MUST publish SSP records as follows:
Note that since the lookup algorithm described below references the immediate parent of the alleged originating domain, it is not necessary to publish SSP records for every single-level label within the domain. This has been done to relieve domain administrators of the burden of publishing an SSP record for every other record in the zone, which would be otherwise required.
Wildcards within a zone, including but not limited to wildcard MX records, pose a particular problem. While referencing the immediate parent domain allows the discovery of an SSP record corresponding to an unintended immediate-child subdomain, wildcard records apply at multiple levels. For example, if there is a wildcard MX record for example.com, the domain foo.bar.example.com can receive mail through the named mail exchanger. Conversely, the existence of the record makes it impossible to tell whether foo.bar.example.com is a legitimate name since a query for that name will not return an NXDOMAIN error. For that reason, SSP coverage for subdomains of domains containing a wildcard record is incomplete.
Signing practices records follow the tag-value syntax described in section 3.2 of [RFC4871]. 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] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from [RFC4234].
ssp-dkim-tag = "dkim" [FWS] "=" [FWS] "unknown" / "all" / "strict"
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) ]
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.
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. The remainder of this session applies only to the third case.
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:
All Signers SHOULD:
Signers wishing to avoid the use of Third-Party Signatures SHOULD do everything listed above, and also:
IANA is requested to create a "DKIM selector name" registry and to reserve the selector name "_ssp" to avoid confusion between DKIM key records and SSP records.
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.
Additional security considerations regarding Sender Signing Practices may be found in the DKIM threat analysis [RFC4686].
[[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
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 [RFC4033].
Because SSP operates within the framework of the legacy e-mail system, the default result in the absence of an SSP record is that the domain does notsign all of its messages. Therefore, a DNS attack which is successful in suppressing the SSP response to the verifier is sufficient to cause the verifier to see unsigned messages as non-suspicious, even when that is not intended by the alleged originating domain.
|[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.|
|[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.|
|[RFC4871]||Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures”, RFC 4871, May 2007.|
|[I-D.ietf-dkim-ssp-requirements]||Thomas, M, “Requirements for a DKIM Signing Practices Protocol”, Internet-Draft draft-ietf-dkim-ssp-requirements-04 (work in progress), April 2007.|
|[RFC4033]||Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, March 2005.|
|[RFC4686]||Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)”, RFC 4686, September 2006.|
From a "diff" perspective, the changes are extensive. Semantically, the changes are:
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 email@example.com.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).