Cloudmark, Inc.

128 King St., 2nd Floor San Francisco CA 94107 US +1 415 946 3800 msk@cloudmark.com

Security Individual submission DKIM Authentication Reputation This experimental specification proposes a modification to Domain Keys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.

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. To enable a third party to apply DKIM signatures to messages, the DKIM specification suggests delegation to a third party of either subdomains or private keys, so that the third party can add DKIM signatures that appear to have been added by the Author ADMD. Absent is a protocol by which an Author ADMD can announce that messages bearing specific valid DKIM signatures on its mail, which are added by other ADMDs, are to be treated as if they were signed by the Author ADMD itself. This memo presents an experimental mechanism for doing so, called Authorized Third-Party Signers (ATPS). ATPS augments the semantics of DKIM by providing to the verifier multiple identifiers rather than one. Specifically, it validates the identifier found in the DKIM signature, and then provides the RFC5322.From domain for evaluation. This memo also registers, per , the means to indicate to agents downstream of the Verifier that a third-party signature verification occurred.

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 .

Readers are advised to be familiar with the material and terminology discussed in and .

The context of this protocol involves the following roles: ADministrative Mail Domain (ADMD)s, whose DNS domain name(s) appear in the RFC5322.From field of a message; ATPS Signers, which apply signatures using their own domains, but on behalf of the message Author's ADMD; and the Verifier, who implements the signature validation procedures described in . An ADMD implements this protocol if it wishes to announce that a signature from any in a set of specified DNS domains is to be considered equivalent to one from the ADMD itself. One might, for example, wish to delegate signing 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 . An authorized ATPS Signer makes a claim of this relationship via new tags in the DKIM signature, and the ADMD confirms this claim by publishing a specific TXT record in its DNS. A Verifier implements this protocol if it wishes to ensure that a message bears one or more signatures from sources authorized to sign mail on behalf of the ADMD, and identify for special treatment mail that meets (or does not meet) that criterion. It will do so by treating the signer's authorization on behalf of the author's ADMD to mean that the signer's signature is equivalent to one affixed by the author's ADMD.

This section describes in detail the queries issued, the replies received, and how they should be interpreted and applied.

The author's ADMD will indicate authorization of a third party to sign its mail via the presence of a DNS TXT record that contains an encoding of the third party's DNS domain name. There are two supported methods for doing so, one that involves a plain copy of the third party's DNS domain name, and one that involves an encoded version of the name. The encoding mechanism is provided so that any domain name can be added to the DNS in a fixed length, so that longer third-party domain names are not excluded from participation because of the overall length limit on a DNS query. If selected, the encoding mechanism requires constructing a digest of the third party's DNS domain name. The author ADMD MUST select a digest ("hash") method currently supported by DKIM (see Section 7.7 of ), and this selection needs to be communicated to the ATPS Signer as it is used in generation of its the third party signatures. Where the encoding mechanism is not used, the ATPS Signer MUST use a hash name of "none". The full DNS mechanism is specified in .

signatures contain a "tag=value" sequence. This protocol will add additional tags called "atps" and "atpsh". When the ATPS Signer generates a DKIM signature for another ADMD, it MUST put its own domain in the signature's "d" tag, and include an "atps" tag that has as its value the domain name of the ADMD on whose behalf it is signing. The tag name that carries the name of the selected hash algorithm is "atpsh". This tag MUST also be included, as it is required as part of the algorithm that will be enacted by the Verifier. The formal syntax definition, per :

dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP ( "none" / key-h-tag-alg )

"domain-name" and "key-h-tag-alg" are defined in . Note that according to , internationalized domain names are to be encoded as A-labels, as described in Section 2.3 of . The registration for these tags can be found in .

When a 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 ), 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 DNS TXT query, as specified below, looking for confirmation by the Author ADMD that the ATPS Signer is authorized by that ADMD 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. Note that the algorithm uses hashing, but this is not a security mechanism. See for discussion. The name for the query is constructed as follows: Select the hash algorithm from the "atpsh" tag in the signature. If the hash algorithm specified does not appear in the list registered with IANA as one valid for use with DKIM (see Section 7.7 of ), and is not the reserved name "none" as described above, abort the query. Extract the value of the "d=" tag from the signature. Convert any upper-case characters in that string to their lower-case equivalents. If the selected hash algorithm is not "none", apply the following additional steps: Feed the resulting string to the selected hash algorithm. Convert the output of the hash to a string of printable ASCII characters by applying base32 encoding as defined in Section 6 of . 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. Append the string "._atps." Append the domain name found in the "atps" tag of the validated signature. The query's formal syntax definition, per :

atps-query = ( 1*63BASE32 / domain-name ) %x2e.5f.61.74.70.73.2e domain-name BASE32 = ( ALPHA / %x32-37 )

The width limit of 63 on the base32 encoding is based on the maximum label limit found in Section 2.3.4 of . See for an example of a query construction.

In the descriptions below, the label NOERROR symbolizes DNS response code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 of for further details. At this time, only three possibilities need to be identified in this specification: An answer is returned (i.e. reply code NOERROR with at least one answer) containing a valid ATPS reply. In this case, the protocol has been satisfied and the Verifier can conclude that the signing domain is authorized by the ADMD to sign its mail. Further queries SHOULD NOT be initiated. No answer is returned (i.e. 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 ADMD, and thus the Verifier MUST continue to the next query, if any. An error is returned (i.e. any other reply code). It is no longer possible to determine whether or not this message satisfies the ADMD'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 either NXDOMAIN or NOERROR with no answers, then the Signer was not authorized by the ADMD. A valid ATPS reply consists of a sequence of tag-value pairs as described in Section 3.2 of . The following tags and values are currently supported in ATPS records: Domain (plain-text; RECOMMENDED) This tag includes a plain-text copy of the DNS domain being authorized as an ATPS Signer. This is included to assist with collision detections; for example, if the base32 encoding of this name is not the same as the base32 portion of the query, or more simply if this name is not the same as that found in the "atps" tag, a hash collision could have occurred. Its use where no name hashing has occurred is redundant. ABNF:

atps-d-tag = %x64 [FWS] "=" [FWS] domain-name ; FWS is defined in [DKIM]

Version (plain-text; REQUIRED) This tag defines the version of this specification that applies to the ATPS record. The record MUST be ignored if the value is not "ATPS1". ABNF:

atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 ; FWS is defined in [DKIM]

For each DKIM signature that verifies (see Section 6 of ), if a Verifier succeeds in confirming that the Author's ADMD authorized the ATPS Signer using this protocol, then the Verifier SHOULD evaluate the message as though it contained a valid signature from the Author's ADMD. It MAY also independently evaluate the ATPS Signer when determining message disposition. This assertion is based on the fact that the ADMD explicitly endorsed the ATPS Signer. Therefore, a module assessing reputation that is based on DKIM signature verification SHOULD apply the reputation of the Author's ADMD domain instead of, or in addition to, that of the ATPS Signer domain.

defined a protocol by which the owner of an Author Domain can advertise a request to message receivers that messages bearing no valid author signature be treated with suspicion or even discarded. A Verifier implementing both ADSP and ATPS MUST test ATPS first. If ATPS indicates a valid delegation, the verifier MUST act, with respect to ADSP, as though the message has a valid Author Domain Signature (because that's what the delegation means), and no ADSP test is required.

The working group that developed DKIM considered a third-party mechanism such as this one to be controversial, in terms of need and practicality, and decided that an alternative mechanism was suffient. However, this was not based on actual experience as there is no specific history on this question. Thus, this experiment was devised. The experimental protocol described here has been implemented as an extension to DKIM in two software products, one of which is open source and seeing increasingly wide use. It is included there to allow customers of those systems to make use of it if they believe such third party assertions are useful to the overall DKIM mechanism. Further adoption as part of the experiment is welcome and encouraged. Use of the protocol and anecdotes of how it affects the overall DKIM experience will be collected by those implementers and the author of this memo. Those participating in the experiment are also advised to observe and report the impact of what is discussed in , especially with respect to MTA latency that may be introduced. If the response is substantial and positive, advancement along the Standards Track might be warranted.

This section enumerates requested IANA actions.

IANA is directed to create an Authorized Third Party Signature (ATPS) Tag Registry, under the DomainKeys Identified Mail (DKIM) Parameters group, 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 . Such registry changes MUST contain the following information: Name of the tag being registered or updated The document where the specification is created or updated 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 | +-----+--------------+---------+

The following is to be added to the Email Authentication Methods Registry (in the Email Authentication Parameters group) established by as per : dkim-atps [THIS MEMO] header from contents of the From: header field, with comments removed

The following are to be added to the Email Authentication Result Names Registry (in the Email Authentication Parameters group) established by as per : none existing dkim-atps No valid DKIM signatures were found on the message bearing "atps" tags. pass existing dkim-atps An ATPS evaluation was performed and a valid signature from an authorized third-party was found on the message. fail existing dkim-atps 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. temperror existing dkim-atps 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 might produce a final result. permerror existing dkim-atps 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.

The following are to be added to the DKIM-Signature Tag Speficication Registry (in the DomainKeys Identifie Mail (DKIM) Parameters group) established by as per :

+-------+-------------+---------+ | TYPE | REFERENCE | STATUS | +-------+-------------+---------+ | atps | [THIS MEMO] | current | +-------+-------------+---------+ | atpsh | [THIS MEMO] | current | +-------+-------------+---------+

This section discusses potential security issues related to this experimental protocol.

The selection of the hash algorithm to be used (see ) has security implications, as weaker algorithms have more risk of collision, meaning a second DNS domain name could in theory be constructed to appear to have been authorized by the Author ADMD. At the time of publication of , use of SHA256 was preferred over SHA1 for this reason, though support for both has been maintained. See Section 3.3 of for additional discussion.

The fact that the authorized third-party domain name is hashed and then encoded with base32 might give some the false sense that the relationship between the two parties is somehow protected. This is not the case. Indeed, the very purpose of this protocol is to make it possible for such relationships to be discovered, so such an obscuration would make that process more difficult without a shared secret delivered out-of-band to message verifiers (which also adds further complexity. Rather, the hash and encode steps are done merely to convert any third-party domain name to a fixed width in the construction of the DNS query.

Approving a third party signer exposes the ADMD to the risk that the third party signer becomes compromised and then begins to sign malicious or nuisance messages on behalf of the ADMD. This can obviously reflect negatively on the ADMD, and the impact of this can become more severe as automated domain reputation systems are developed and deployed. Thorough vetting and monitoring practices by ADMDs of third party signers will likely need to become the norm.

A Verifier participating in DKIM, ADSP and ATPS will now issue a number of TXT queries to the DNS equal to as many as one (for the ADSP query) plus the number of signatures on the message (one for each key that is to be verified) plus the number of signatures that validated which also bear an "atps" tag. This is in addition to any PTR and A queries the MTA might 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 ADMD 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. See Section 8.5 of for further discussion of DNS-related issues.

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, inter-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK] Sendmail, Inc. This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. SJD Brandenburg InternetWorking AT&T Laboratories Cloudmark DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. [STANDARDS TRACK] USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Over its thirty-five year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants must work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. Qualcomm Incorporated

5775 Morehouse Drive San Diego CA 92121-1714 US +1 858 651 4478 presnick@qualcomm.com http://www.qualcomm.com/~presnick/

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. Sendmail, Inc. Cisco Systems, Inc. Yahoo!, Inc. Taughannock Networks DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.

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" tag whose value is "example.com", and no "atpsh" tag is present in either. The following actions are taken: A SHA1 hash of "one.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". A TXT query is issued to "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". If a valid reply arrives, the algorithm stops with result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate. A SHA1 hash of "two.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". A TXT query is issued to "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". If a valid reply arrives, the algorithm stops with result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate. As there are no valid signatures left to test, the algorithm stops with an "unknown" result.

It was proposed that this work appear within the DNS under a new Resource Record (RR) Type. Although this is possibly an appropriate thing to do, consideration was also given to the fact that major portions of DKIM already use an ASCII-based "tag=value" syntax, and store key and ADSP data in the DNS using TXT resource records. To enable re-use of existing DKIM code, it was decided to re-use the TXT message scheme.

The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark Martinec and Phil Pennock for their review and constructive criticism of this proposal. The author also wishes to acknowledge Doug Otis and Daniel Black for their original draft upon which this work was based.