Individual submission M. Kucherawy Internet-Draft Cloudmark, Inc. Updates: 5617 (if approved) August 2, 2011 Intended status: Experimental Expires: February 3, 2012 DKIM Authorized Third-Party Signers draft-kucherawy-dkim-atps-06 Abstract This memo presents an experimental proposal to supplement Domain Keys Identified Mail (DKIM) by allowing advertisement of third-party signature authorizations on behalf of an email originator. This memo updates RFC5617. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Kucherawy Expires February 3, 2012 [Page 1] Internet-Draft DKIM ATPS Experiment August 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . 3 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Queries and Replies . . . . . . . . . . . . . . . . . . . . . 4 4.1. Extension to DKIM . . . . . . . . . . . . . . . . . . . . 4 4.2. ATPS Query Details . . . . . . . . . . . . . . . . . . . . 4 4.3. ATPS Reply Details . . . . . . . . . . . . . . . . . . . . 5 5. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 7 7.2. Email Authentication Method Name Registry Update . . . . . 7 7.3. Email Authentication Result Name Registry Update . . . . . 8 7.4. DKIM-Signature Tag Specification Registry . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Transient Security Failures . . . . . . . . . . . . . . . 9 8.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Kucherawy Expires February 3, 2012 [Page 2] Internet-Draft DKIM ATPS Experiment August 2011 1. Introduction [DKIM] defines a mechanism for transparent domain-level signing of messages for the purpose of declaring that a particular Administrative Mail Domain (ADMD) takes some responsibility for a message. DKIM, however, deliberately makes no binding between the DNS domain of the signer and any other identity found in the message. Despite this, there is an automatic human perception that an author domain signature (one for which the RFC5322.From domain matches the DNS domain of the signer) is more valuable or trustworthy than any other. Absent is a protocol by which an ADMD can announce that DKIM signatures on its mail added by other ADMDs should also be considered trustworthy by verifiers. This memo presents an experimental mechanism for doing so. 2. Definitions 2.1. Keywords 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 [KEYWORDS]. 2.2. E-Mail Architecture Terminology Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. 3. Discussion Participation in this protocol is divided into three parties: o Authors, whose domains appear in the RFC5322.From field of a [MAIL] message; o Signers, who send mail on behalf of Authors and apply [DKIM] signatures using their own domains; and o Verifiers, who implement the signature validation procedures described in [DKIM]. An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. One might, for example, wish to delegate signing Kucherawy Expires February 3, 2012 [Page 3] Internet-Draft DKIM ATPS Experiment August 2011 authority for its DNS domain to an approved messaging service provider without doing the work of key transfer described in Appendix B.1.1 of [DKIM]. A Verifier participates in this protocol if it wishes to ensure that a message bears one or more signatures from sources approved to sign mail on behalf of the Author, and identify for special treatment mail that meets (or does not meet) that criterion. A Verifier with this interest has presumably already implemented DKIM and is therefore making one DNS query for each DKIM signature (to retrieve the matching public key) on the message, and perhaps one to apply the protocol defined in [ADSP]. Therefore, a tag indicating this extension will be added to DKIM's signature tag list. 4. Queries and Replies This section describes in detail the queries issued, the replies received, and how they should be interpreted and applied. 4.1. Extension to DKIM [DKIM] signatures contain a "tag=value" sequence. This protocol will add an additional tag called "atps". When the Signer generates a DKIM signature on behalf of an Author, it MUST include this tag in the signature and include as its value the Author's domain name. The formal syntax definition, per [ABNF]: dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name "domain-name" is imported from [DKIM]. The registration for this tag can be found in Section 7. 4.2. ATPS Query Details When a [DKIM] signature including an "atps" tag is successfully verified, and is considered acceptable to the Verifier according to any local policy requirements (which are not discussed here or in [DKIM]), the Verifier compares the domain name in the value of that tag with the one found in the RFC5322.From field of the message. The match MUST be done in a case-insensitive manner. If they do not match, the "atps" tag MUST be ignored. If they do match, the Verifier issues a TXT query to the DNS to a specific name looking for confirmation by the Author that the Signer Kucherawy Expires February 3, 2012 [Page 4] Internet-Draft DKIM ATPS Experiment August 2011 is authorized by the Author to sign mail on its behalf. Where multiple DKIM signatures are present including valid "atps" tags, these queries MAY be done in any order or MAY be done in parallel. Where the RFC5322.From field contains multiple addresses, this process SHOULD be applied if the "atps" tag's value matches any of the domains found in that field. These MAY be done in any order. The name for the query is constructed as follows: 1. Extract the value of the "d=" tag from the signature. 2. Convert any upper-case characters in that string to their lower- case equivalents. 3. Feed the resulting string to the [SHA1] hash algorithm. 4. Convert the output of the SHA1 hash to a string of 32 alphanumeric characters by applying base32 encoding as defined in Section 6 of [BASE32]. The base32 encoding is used because its output is restricted to characters that are legal for use in labels in the DNS, and evaluates the same way in the DNS whether encoded using uppercase or lowercase characters. 5. Append the string "._atps." 6. Append the domain name found in the "atps" tag of the validated signature. The query's formal syntax definition, per [ABNF]: atps-query = 32*BASE32 %x2e.5f.61.74.70.73.2e domain-name BASE32 = ( ALPHA / %x32-37 ) See Appendix A for an example of a query construction. Since the size of a [DNS] query is limited to 255 bytes, the size of "domain-name" in the ABNF above is constrained to 216 bytes. 4.3. ATPS Reply Details In the descriptions below, the label NOERROR symbolizes DNS response code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 of [DNS] for further details. At this time, only three possibilities need to be identified in this specification: Kucherawy Expires February 3, 2012 [Page 5] Internet-Draft DKIM ATPS Experiment August 2011 o An answer is returned (i.e. [DNS] reply code NOERROR with at least one answer) containing a valid ATPS reply. In this case, the protocol has been satisfied and the Verifier may conclude that the signing domain is authorized by the Author to sign its mail. Further queries SHOULD NOT be initiated. o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR with no answers), or one or more answers have been returned as described above but none contain a valid ATPS reply. In this case, the Signer has not been authorized to act as a third-party signer for this Author, and thus the Verifier MUST continue to the next query. o An error is returned (i.e. any other [DNS] reply code). It is no longer possible to determine whether or not this message satisfies the Author's list of authorized third-party signers. The Verifier SHOULD stop processing and defer the message for later processing, such as requesting temporary failure code from the MTA. If all queries are completed and return NXDOMAIN, then the Signer was not authorized by the Author. A valid ATPS reply consists of a sequence of tag-value pairs as described in Section 3.2 of [DKIM]. The following tag and value is the only one currently supported in ATPS records: v: Version (plain-text; REQUIRED) This tag defines the version of this specification that applies to the ATPS record. It MUST have the value "ATPS1". ABNF: atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 5. Interpretation If a Verifier succeeds in confirming that the Author authorized the Signer using this protocol, then the Verifier SHOULD evaluate the message as though the Signer is the Author. This assertion is based on the fact that the Author explicitly endorsed the Signer. Therefore, a module assessing reputation that is based on DKIM signature verification SHOULD apply the reputation of the Author domain instead of, or in addition to, that of the Signer domain. 6. Relationship to ADSP [ADSP] defined a protocol by which an Author can advertise a request to message receivers that messages bearing no valid author signature Kucherawy Expires February 3, 2012 [Page 6] Internet-Draft DKIM ATPS Experiment August 2011 be treated with suspicion or even discarded. A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. 7. IANA Considerations No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. 7.1. ATPS Tag Registry An Authorized Third Party Signature (ATPS) Tag Registry will be created by IANA to enumerate the tags that are valid for use in ATPS records. New registrations or updates MUST be published in accordance with the "Specification Required" guidelines described in [IANA-CONSIDERATIONS]. Such registry changes MUST contain the following information: 1. Name of the tag being registered or updated 2. The document where the specification is created or updated 3. The status of the tag, one of "current" (tag is in current use), "deprecated" (tag is in current use but its use is discouraged), or "historic" (tag is no longer in use) The registry's sole initial entry is: +-----+--------------+---------+ | Tag | Specified In | Status | +-----+--------------+---------+ | v | [this memo] | current | +-----+--------------+---------+ 7.2. Email Authentication Method Name Registry Update The following should be added to the Email Authentication Method Name Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: Method dkim-atps Kucherawy Expires February 3, 2012 [Page 7] Internet-Draft DKIM ATPS Experiment August 2011 Defined In [THIS MEMO] ptype header property from value contents of the [MAIL] From: header field, with comments removed 7.3. Email Authentication Result Name Registry Update The following should be added to the Email Authentication Result Name Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: Code none Existing/New Code existing Defined In [AUTHRES] Auth Method dkim-atps Meaning No valid DKIM signatures were found on the message bearing "atps" tags. Code pass Existing/New Code existing Defined In [AUTHRES] Auth Method dkim-atps Meaning An ATPS evaluation was performed and a valid signature from an authorized third-party was found on the message. Code fail Existing/New Code existing Defined In [AUTHRES] Auth Method dkim-atps Meaning All valid DKIM signatures bearing an "atps" tag either did not reference a domain name found in the RFC5322.From field, or the ATPS test(s) performed failed to confirm a third-party authorization. Kucherawy Expires February 3, 2012 [Page 8] Internet-Draft DKIM ATPS Experiment August 2011 Code temperror Existing/New Code existing Defined In [AUTHRES] Auth Method dkim-atps Meaning An ATPS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error. A later attempt may produce a final result. Code permerror Existing/New Code existing Defined In [AUTHRES] Auth Method dkim-atps Meaning An ATPS evaluation could not be completed due to some error that is not likely transient in nature, such as a permanent DNS error. A later attempt is unlikely to produce a final result. 7.4. DKIM-Signature Tag Specification Registry The following should be added to the DKIM-Signature Tag Speficication Registry established by [DKIM] as per [IANA-CONSIDERATIONS]: +------+-------------+ | TYPE | REFERENCE | +------+-------------+ | atps | [THIS MEMO] | +------+-------------+ 8. Security Considerations This section discusses potential security issues related to this experimental protocol. 8.1. Transient Security Failures Approving a third party signer exposes the Author to the risk that the third party signer becomes compromised and then begins to sign malicious or nuisance messages on behalf of the Author. This can obviously reflect negatively on the Author, and the impact of this can become more severe as automated domain reputation systems are developed and deployed. Thorough vetting and monitoring practices by Kucherawy Expires February 3, 2012 [Page 9] Internet-Draft DKIM ATPS Experiment August 2011 Authors of third party signers will likely need to become the norm. 8.2. Load on the DNS A Verifier participating in DKIM, ADSP and ATPS will now issue a number of TXT queries to the DNS equal to one (for the ADSP query) plus twice the number of valid signatures on the message (one for each key, one for an ATPS record) plus the number of invalid signatures on the message (one for each key). This is in addition to any PTR and A queries the MTA may issue at the time the actual message relaying or delivery is initiated. Obviously this can be burdensome on the DNS at both ends, and waiting for that number of queries to return when they are issued in parallel could trigger timeouts in the MTA. An alternative to this that has not yet been explored is the storage of the ATPS data at a specific URL tied to the Author's domain name. This would alleviate pressure on the DNS at the expense of requiring the Author to operate a web server (which has its own security implications) and the addition of the establishment of a TCP connection. Moreover, the Verifier would be well advised to implement caching of this data to prevent ATPS from being used as a denial-of-service vector. 9. References 9.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Kucherawy Expires February 3, 2012 [Page 10] Internet-Draft DKIM ATPS Experiment August 2011 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SHA1] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-2, August 2002. 9.2. Informative References [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, October 2008. [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Appendix A. Example Query and Reply This section presents an example of the use of this protocol to query for a third-party authorization and discusses the interpretation of the result. Presume a message for which the RFC5322.From domain is "example.com", and it bears two valid signatures, from "one.example.net" and from "two.example.net", each with an "atps" whose value is "example.com". The following actions are taken: 1. A SHA1 hash of "one.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 2. A TXT query is issued to "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 3. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate. Kucherawy Expires February 3, 2012 [Page 11] Internet-Draft DKIM ATPS Experiment August 2011 4. A SHA1 hash of "two.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 5. A TXT query is issued to "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 6. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate. 7. As there are no valid signatures left to test, the algorithm stops with an "unknown" result. Appendix B. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Dave Crocker, Mark Martinec The author also wishes to acknowledge Doug Otis and Daniel Black for their original draft upon which this work was based. Author's Address Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US Phone: +1 415 946 3800 EMail: msk@cloudmark.com Kucherawy Expires February 3, 2012 [Page 12]