Network Working Group S. Atkins Internet-Draft Word to the Wise Intended status: Standards Track J. Falk Expires: August 3, 2008 Return Path J. Levine, Ed. Taughannock Networks W. Venema IBM T. J. Watson Research January 31, 2008 DKIM Author Signing Practices (ASP) draft-levine-asp-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 August 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 Atkins, et al. Expires August 3, 2008 [Page 1] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 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 authors can use to advertise their practices for signing their outgoing mail, and how other hosts can access those records. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 3 2.1. Terms Imported from DKIM Signatures Specification . . . . 3 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 4 2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 4 2.6. Alleged Authors . . . . . . . . . . . . . . . . . . . . . 4 2.7. Author Signing Practices . . . . . . . . . . . . . . . . . 4 2.8. Author Signature . . . . . . . . . . . . . . . . . . . . . 4 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ASP Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. ASP Results . . . . . . . . . . . . . . . . . . . . . . . 5 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 6 4.2. Publication of ASP Records . . . . . . . . . . . . . . . . 6 4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Author Signing Practices Lookup Procedure . . . . . . . . 8 5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Single Location Domains . . . . . . . . . . . . . . . . . 9 5.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 10 5.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 10 5.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. References - Normative . . . . . . . . . . . . . . . . . . 11 6.2. References - Informative . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Atkins, et al. Expires August 3, 2008 [Page 2] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 1. Introduction Much of this document is adapted from [I-D.ietf-dkim-ssp-01] by Allman et al. The features described here are approximately a subset of the ones described in that document. 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 is very likely that most messages will remain unsigned. However, some domains might decide 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 other hosts. This is the topic of Author Signing Practices (ASP). In the absence of a valid DKIM signature, hosts implementing this specification can inquire what Author Signing Practices that domain advertises. This inquiry is called an Author Signing Practices check. The detailed requirements for Author Signing Practices are given in [I-D.ietf-dkim-ssp-requirements]. This document refers extensively to [RFC4871] and assumes the reader is familiar with it. Requirements Notation: 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] 2. Language and Terminology 2.1. Terms Imported from DKIM Signatures Specification Some terminology used herein is derived directly from [RFC4871]. In several cases, references in that document to Sender have been changed to Author here, to emphasize the relationship to the Author address(es) on the From: header line described in [RFC2822]. Briefly, Atkins, et al. Expires August 3, 2008 [Page 3] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 o 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. o A "Selector" specifies which of the keys published by a signing domain is to be queried. It is essentially a way of subdividing the address space to allow a single sending domain to publish multiple keys. 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 [RFC4871]. 2.3. Author Address An "Author Address" is an email address in the From header field of a message [RFC2822]. If the From header field contains multiple addresses, the message has multiple Author Addresses. 2.4. Author Domain An "Author Domain" is everything to the right of the "@" in an Author Address (excluding the "@" itself). 2.5. Alleged Signer An "Alleged Signer" is the identity of the signer claimed in a DKIM- Signature header field in a message received; it is "alleged" because it has not yet been verified. 2.6. Alleged Authors An "Alleged Author" is an Author Address of a message; it is "alleged" because it has not yet been verified. 2.7. Author Signing Practices "Author Signing Practices" (or just "practices") consist of a machine-readable record published by the domain of an Alleged Author which includes statements about the domain's practices with respect to mail it sends with its domain in the From: line. 2.8. Author Signature An "Author Signature" is any Valid Signature where the signing domain (listed in the "i=" tag if present, otherwise its default value, consisting of the value of the "d=" tag) matches the domain of an Atkins, et al. Expires August 3, 2008 [Page 4] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 Author Address. 3. Operation Overview A host typically looks up Author Signing Practices based on the Author Address(es). Hosts can look up the Author Signing Practices of the domain(s) specified by the Author Address(es) as described in Section 4.4. 3.1. ASP Usage Depending on the Author Domain(s) and the signatures in a message, a recipient gets varying amounts of useful information from an ASP lookup. o If a message has no Valid Signature, the ASP result is directly relevant to the message. o If a message has a Valid Signature from an Author Domain, ASP provides no benefit relative to that domain since the message is already known to be compliant with any possible ASP for that domain. o If a message has a Valid Signature from a domain other than an Author Domain, the receiver can use both the Signature and the ASP result in its evaluation of the message. 3.2. ASP Results An Author Signing Practices lookup produces one of four possible results: o Messages from this domain might or might not have an author signature. This is the default if the domain exists but no record is found. o All messages from this domain are signed. o All messages from this domain are signed and discardable. o The domain does not exist. Atkins, et al. Expires August 3, 2008 [Page 5] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 4. Detailed Description 4.1. DNS Representation Author Signing Practices records are published using the DNS TXT resource record type. NON-NORMATIVE DISCUSSION [to be removed before publication]: There has been considerable discussion on the DKIM WG mailing list regarding the relative advantages of TXT and a new resource record (RR) type. Read the archive for details. The RDATA for ASP resource records is textual in format, with specific syntax and semantics relating to their role in describing Author 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 ASP, although they MAY cause the logging of warning messages via an appropriate system logging mechanism. If the RDATA contains multiple character strings, the strings are logically concatenated with no delimeters between the strings. ASP records for a domain are published at a location in the domain's DNS hierarchy prefixed by _asp._domainkey.; e.g., the ASP record for example.com would be a TXT record that is published at _asp._domainkey.example.com. A domain MUST NOT publish more than one ASP record; the semantics of an ASP lookup that returns multiple ASP records for a single domain are undefined. (Note that example.com and mail.example.com are different domains.) 4.2. Publication of ASP Records Author Signing Practices are intended to apply to all mail sent from a 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: o The domain itself o Subdomains which might or might not be used for email o Host names which might or might not be used for email o Other named resource records in the domain o Multi-level examples of the above, e.g., a.b.example.com Atkins, et al. Expires August 3, 2008 [Page 6] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 o Non-existent cases, i.e., a subdomain or hostname that does not actually exist within the domain A domain publishing Author Signing Practices may want to do so for both itself and all of its "descendants" (child domains and hosts, at all lower levels). Domains wishing to do so publish ASP records as follows: o Publish an ASP record for the domain itself. o Publish an ASP record for any existing subdomain. Note that since the lookup algorithm described below references the immediate parent of the alleged originating domain, it is not necessary to publish ASP records for every single-level label within the domain. This has been done to relieve domain administrators of the burden of publishing an ASP record for every other record in the domain, which would be otherwise needed. Wildcards within a domain, including but not limited to wildcard MX records, pose a particular problem. While referencing the immediate parent domain allows the discovery of an ASP 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, ASP coverage for subdomains of domains containing a wildcard record is incomplete. NON-NORMATIVE NOTE [to be removed before publication]: Complete ASP coverage of domains containing (or where any parent contains) wildcards generally cannot be guaranteed. 4.3. Record Syntax ASP records follow the "tag=value" syntax described in section 3.2 of [RFC4871]. The ASP record syntax is a tag-list as defined in that section, including the restriction on duplicate tags, the use of white space, and case sensitivity. Tags used in ASP records are as follows. Unrecognized tags MUST be ignored. In the ABNF below, the ALPHA and DIGIT tokens are imported from [RFC4234]. Atkins, et al. Expires August 3, 2008 [Page 7] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 dkim= Outbound signing practices for the domain (plain-text; REQUIRED). Possible values are as follows: unknown The domain might sign some or all email. all All mail from the domain is signed with an Author Signature. discardable All mail from the domain is signed with an Author Signature. Furthermore, if a message arrives without a valid Author Signature due to modification in transit, submission via a path without access to a signing key, or other reason, the domain encourages the recipient(s) to discard it. ABNF: asp-dkim-tag = "dkim=" ("unknown" / "all" / "discardable") t= Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is that no flags are set). Flag values are: s The signing practices apply only to the named domain, and not to subdomains. ABNF: asp-t-tag = %x75 "=" asp-t-tag-flag 0*( ":" asp-t-tag-flag ) asp-t-tag-flag = "s" / hyphenated-word ; for future extension hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] Unrecognized flags MUST be ignored. 4.4. Author Signing Practices Lookup Procedure To look up the Author Signing Practices of a domain, ASP Checkers doing an ASP lookup MUST produce a result that is semantically equivalent to applying the following steps in the order listed below. In practice, several of these steps can be performed in parallel in order to improve performance. However, implementations SHOULD avoid doing unnecessary DNS lookups. For the purposes of this section a "valid ASP record" is one that is both syntactically and semantically correct; in particular, it must match the ABNF for a "tag-list" and must include a defined "dkim=" tag. 1. The host makes a DNS query for a TXT record corresponding to the domain prefixed by "_asp._domainkey.". If the result of this Atkins, et al. Expires August 3, 2008 [Page 8] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 query is a NOERROR response with an answer which contains a syntactically-valid ASP record, the Author Signing Practices are described by the contents of the record and the algorithm terminates. 2. The host MUST query DNS for an MX record corresponding to the domain (with no prefix). This query is made only to check the existence of the domain name and MAY be done in parallel with the query made in step 1. If the result of this query is an NXDOMAIN error, the domain does not exist and the algorithm terminates. NON-NORMATIVE DISCUSSION [to be removed before publication]: Any resource record type could be used for this query since the existence of a resource record of any type will prevent an NXDOMAIN error. The choice of MX for this purpose is because this record type is thought to be the most common for likely domains, and will therefore result in a result which can be more readily cached than a negative result. 3. The host MUST query DNS for a TXT record for the immediate parent domain, prefixed with "_asp._domainkey." If the result of this query is a NOERROR response with one or more answers that are syntactically-valid ASP responses, and the responses do not contain a "s" flag, the Author Signing Practices are described by the contents of the record(s). If any of the queries involved in the Author Signing Practices Check result in a SERVFAIL error response, the host MAY either queue the message or return an SMTP error indicating a temporary failure. 5. Usage Examples These examples are intended to illustrate typical uses of ASP. They are not intended to be exhaustive, nor to apply to every domain or mail system's individual situation. 5.1. Single Location Domains A common mail system configuration handles all of a domain's users' incoming and outgoing mail through a single MTA or cluster of MTAs. In that case, the MTA(s) can be configured to sign outgoing mail with an Author Signature. In this situation it might be appropriate to publish an ASP record for the domain containing "all", depending on whether the users also send mail through other MTAs that do not apply an Author Signature. Such MTAs could include MTAs at hotels or hotspot networks used by Atkins, et al. Expires August 3, 2008 [Page 9] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 travelling users, or web sites that provide "mail an article" features. Domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature, such as mailing lists, courtesy forwarders, and other paths that could add or modify headers, or modify the message body. In that case, if the modifications invalidate the DKIM signature, recipient MTAs will consider the mail not to have an Author Signature, even though the signature was present when the mail was originally sent. 5.2. Bulk Mailing Domains Another common configuration uses a domain solely for bulk or broadcast mail, with no individual human users, again typically sending all the mail through a single MTA or cluster of MTAs that can apply an Author Signature. In this case, the domain's management can be confident that all of its outgoing mail will be sent through the signing MTA. Lacking individual users, the domain is unlikely to participate in mailing lists, but could still send mail through other paths that might invalidate signatures. Domain owners often use specialist mailing providers to send their bulk mail. In that case, the mailing provider needs access to a suitable signing key in order to apply an Author Signature. One possible route would be for the domain owner to generate the key and give it to the mailing provider. Another would be for the domain to delegate a subdomain to the mailing provider, for example, bigbank.example might delegate email.bigbank.example to such a provider. In that case, the provider can generate the keys and DKIM DNS records itself and use the subdomain in the Author address in the mail. 5.3. Bulk Mailing Domains with Discardable Mail In some cases, a domain might sign all its outgoing mail with an Author Signature, but prefers that recipient systems discard mail without a valid Author Signature to avoid confusion from mail sent from sources that do not apply an Author Signature. (This latter kind of mail is sometimes loosely called "forgeries".) In that case, it may be appropriate to publish an ASP record containing "discardable". Note that a domain SHOULD NOT publish a "discardable" record if it wishes to maximize the likelihood that mail from the domain is delivered, since it could cause some fraction of the mail the domain sends to be discarded. As a special case, if a domain sends no mail at all, it can safely Atkins, et al. Expires August 3, 2008 [Page 10] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 publish a "discardable" ASP record, since any mail with an author address in the domain is a forgery. 5.4. Third Party Senders Another common use case is for a third party to enter into an agreement whereby that third party will send bulk or other mail on behalf of a designated author domain, using that domain in the RFC2822 From: or other headers. Due to the many and varied complexities of such agreements, third party signing is not addressed in this specification. The authors anticipate that as mail systems gain experience with DKIM, it will become possible to codify best practices of this and other usages of DKIM. 6. References 6.1. References - Normative [I-D.ietf-dkim-ssp-requirements] Thomas, M., "Requirements for a DKIM Signing Practices Protocol", April 2007. [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. 6.2. References - Informative [I-D.ietf-dkim-ssp-01] Allman, E., Delany, M., and J. Fenton, "DKIM Sender Signing Practices", September 2007. Appendix A. Acknowledgements This document adapted large sections from a previous draft by Eric Allman, Jim Fenton, et al. It greatly benefited from comments by Jon Callas, Dave Crocker, Arvel Hathcock, Ellen Siegel, and Michael Atkins, et al. Expires August 3, 2008 [Page 11] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 Thomas. Authors' Addresses Steve Atkins Word to the Wise PO Box 7086 San Carlos, CA 94070-7086 US Phone: +1 650 678 3453 Email: steve-asp@wordtothewise.com URI: http://wordtothewise.com/ J. D. Falk Return Path 100 Superior Plaza Way Superior, CO 80027 Phone: +1 303 642 4100 Email: ietf@cybernothing.org John Levine (editor) Taughannock Networks PO Box 727 Trumansburg, NY 14886 Phone: +1 831 480 2300 Email: standards@taugh.com URI: http://www.taugh.com Wietse Venema IBM T. J. Watson Research 19 Skyline Drive Hawthorne, NY 10532 Email: wietse@watson.ibm.com Atkins, et al. Expires August 3, 2008 [Page 12] Internet-Draft DKIM Author Signing Practices (ASP) January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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). Atkins, et al. Expires August 3, 2008 [Page 13]