Delegating DKIM Signing Authority
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Murray Kucherawy , Dave Crocker|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group M. Kucherawy Internet-Draft Intended status: Experimental D. Crocker Expires: December 9, 2014 Brandenburg InternetWorking June 7, 2014 Delegating DKIM Signing Authority draft-kucherawy-dkim-delegate-00 Abstract DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. 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 December 9, 2014. Copyright Notice Kucherawy & Crocker Expires December 9, 2014 [Page 1] Internet-Draft DKIM-Delegate June 2014 Copyright (c) 2014 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 described in the Simplified BSD License. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DKIM-Delegate Specification . . . . . . . . . . . . . . . . . 4 3.1. Design Summary . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Specification . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Considerations for Secondary Signatures . . . . . . . . . . . 6 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Detecting Header Changes . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Kucherawy & Crocker Expires December 9, 2014 [Page 2] Internet-Draft DKIM-Delegate June 2014 1. Background DomainKeys Identified Mail [RFC6376] defines a mechanism whereby a verified domain name can be attached to a message, using a cryptographic signature. It does not, however, assert that this domain name matches a domain name found anywhere else in the message. DKIM signature survival is usually successful through basic email relaying nodes. It also survives simple Mediators, such as mailbox forwarding agents, because they only modify the message envelope and do not modify the original message header or body. Transit through other Mediators, such as mailing lists, is usually problematic, because they modify portions of the message covered by the signature and therefore invalidate it. When a receiver needs to determine whether a message was legitimately processed by a purported original signer, a mechanism is needed that is more likely to survive transit through Mediators. This need is especially strong for environments wishing to enforce policy linkage between the author, the author's domain and specific email service providers, such as when the latter two are the same. An example of such a need is when that original signer publishes policies concerning the use of its domain name. Examples are ADSP [RFC5617] and DMARC [I-D.KUCHERAWY-DMARC-BASE]. These policies cannot be applied properly when legitimate mail for the original signer's domain cannot be validated by the final Receiver. The potential for malfunction otherwise is described in Section 5.2 of [RFC6377]. The issues with mailing lists and similar re-mailing applications can be resolved by a mechanism that permits the original signer's domain ("A") to indicate that some other domain ("B") is explicitly permitted to re-sign content generated by "A", such that a Receiver can observe signaling from both "A" and "B" that this relationship exists. An experimental attempt to do this appeared in [RFC6541]. The method presented there imposes a burden on the original signing domain to publish those relationships a priori, via the DNS. This proved cumbersome with poor scaling properties. So, a mechanism that does not have such an external dependency is preferred. 2. Definitions Numerous terms used here, especially "Author", "Originator", "Receiver", and "Recipient", are defined in [RFC5598]. DKIM-related terminology, such as "Signing Domain", are taken from the DKIM specification [RFC6376]. Kucherawy & Crocker Expires December 9, 2014 [Page 3] Internet-Draft DKIM-Delegate June 2014 3. DKIM-Delegate Specification An email header field, called "DKIM-Delegate", is defined. When present, it asserts an ephemeral relationship between an original message signing domain and a later intermediary (Mediator). 3.1. Design Summary An "Original Signer" (typically the Originator serving the Author) affixes two DKIM signatures to a message. One is of the usual type, covering the entire message, and the second is tailored to better survive transit through Mediators such as authorized mailing lists. A DKIM-Delegate field is added to the message, to indicate that this mechanism is in force; this is covered by the second signature (and possibly, but not necessarily, the first). Optionally, a Mediator also signs the message, to provide a reliable indication of handling by the Mediator. If a Receiver finds that the Original Signer's "normal" signature does not validate or is missing, it can perform DKIM-Delegate evaluation. In combination with DKIM signatures, this mechanism can aid a receiver in assessing whether the message was legitimately handled by the intermediary and whether the message was likely to have had a legitimate signature by the original signing domain, even when that original signature became invalid. This makes it possible to identify such messages separately from those without these assurances, and thus permits treating the latter with more skepticism. 3.2. Specification The specific mechanism operates as follows: 1. A "Primary" DKIM Signature is affixed to a message by a handling agent, identifying the Originator's domain and using typical signing choices, such as covering the entire message content in the body hash. (That is, it does not use the "l=" tag.) 2. The signer adds a DKIM-Delegate header field identifying the Originator's domain. It can also identify the specific domain(s) with which it wishes to claim an ephemeral relationship; absent this indication, the list of candidate domains is implicit from elsewhere in the message header (see below). 3. The signer affixes a "Secondary" DKIM signature that is configured so as to better survive transit through the delegated domain(s). The distinctive characteristic of a Secondary Kucherawy & Crocker Expires December 9, 2014 [Page 4] Internet-Draft DKIM-Delegate June 2014 signature is that its hashes cover less of the message; it also might use more permissive canonicalization and/or have an especially short expiration time. The signature MUST cover the DKIM-Delegate header field, in order to validate its use for the message. Suggestions for details of a Secondary signature are discussed in Section 4. 4. An authorized Mediator SHOULD affix its own, normal DKIM signature to the message. 5. The Receiver attempts to validate the primary signature affixed by the original signer. If it is valid, the requirements of this profile are satisfied (and the algorithm terminates here). 6. The Receiver attempts to validate the Secondary (delegation) signature affixed by the original signer. If it is not valid (or not found), the requirements of this profile cannot be satisfied (and the algorithm terminates here). 7. The Receiver confirms that the Secondary signature header hash includes at least the DKIM-Delegate header field, and that the "d=" value in the Secondary signature matches the "d=" value in the DKIM-Delegate field. If either is not true, the requirements of this profile cannot be satisfied (and the algorithm terminates here). 8. If the DKIM-Delegate field includes a list of domain names to which delegation of re-signing authority is claimed, call this set "D". 9. If the DKIM-Delegate signature does not include such a list, the Receiver collects all header fields that were covered by the header hash of the Secondary DKIM signature and that contain recipient addresses. These can be found in that signature's "h=" tag. The obvious examples are the To and Cc fields (if present). The Receiver extracts the set of domain names from the collected header fields, and calls this set "D". 10. The Receiver performs normal validation checks of all other DKIM signatures on the message that include the entire message body in their body hashes, and stores the set of domains from passing signatures in set "S". 11. If the intersection of "D" and "S" is not empty, the requirements of this profile are satisfied; otherwise, the requirements are not satisfied. Kucherawy & Crocker Expires December 9, 2014 [Page 5] Internet-Draft DKIM-Delegate June 2014 3.3. Syntax The content of the DKIM-Delegate header field is a tag-list as defined in Section 3.2 of [RFC6376]. The valid tags are: d= Author domain (plain-text; REQUIRED). This value names the domain of the Author, which is delegating signing authority to one or more other domains. t= Delegation target (plain-text; OPTIONAL). This value is a comma- separated list of domain names to which the authority to sign on behalf of the Author domain is being delegated. When not present, this list is inferred from the domain names present in the recipient fields (To, Cc) of the header. As with DKIM itself, any other tag MUST be ignored. 4. Considerations for Secondary Signatures The Secondary (delegation) signature MUST cover at least the DKIM- Delegate field and the visible recipient fields of the message, but might not cover any of the content. Under this profile, domains that appear in the explicit delegation list (or are otherwise inferred from the recipient header fields) are permitted to alter and re-send the content. Delegated domains SHOULD sign the message. However, receivers MAY accept a Secondary signature for messages lacking a delegated signature if the receiver can otherwise determine that the message was handled through a delegated domain. Original signers need to tailor the secondary signature to best survive transit through the designated Mediators. Settling on a common signing profile for these delegation "tokens" is likely to change with experience. A reasonable example signature profile could cover the following header fields: o From (required by DKIM) o To and Cc (contain Receiver addresses) o Message-Id (binds the signature to a specific message) o Date (binds the signature to a specific date and time) Kucherawy & Crocker Expires December 9, 2014 [Page 6] Internet-Draft DKIM-Delegate June 2014 o DKIM-Delegate (signals to participating receivers that an ephemeral delegation of signing authority is in effect) Subject, though normally covered by signatures as per Section 5.4 of [RFC6376], can be omitted for a Secondary signature if the original signer anticipates legitimate alteration of it by a Mediator. See also Section 5.1. The Secondary signature might cover the message content, but allow for legitimate Mediator modifications by including an "l=" tag in the signature. This would require the Mediator to restict its alterations to involve appended content only. Hence the Secondary signature can use an "l=" value reflecting the entire message as generated by the Author, or "0" (zero) allowing a complete reformatting of the message. Obviously the latter grants the Mediator considerable latitude in what it will ultimately emit, while the former is much more constrained. The original signer of the message can choose whichever is more appropriate for its own policies and requirements. This use of DKIM's "l=" value assumes messages sent to the Mediator that are not part of a multipart message structure, as described in Multipurpose Internet Mail Extensions (MIME; see [RFC2045]). It might not be possible to select a practical signing length for messages in other than the basic message format. The expiration time on the Secondary signature needs to be long enough to permit evaluation by receivers of the re-submitted message, yet short enough to limit the potential for unauthorized replay attacks. A good choice is a small number of days or even hours. 5. Discussion The use of the Primary signature ensures that if the original message arrives unmodified, the Receiver is assured of its legitimacy as having been generated and sent by the original signer, irrespective of what Mediator handled it. Mediators, such as mailing list software, commonly make adjustments to a message prior to re-submitting it for transfer to final recipients. Adjustments often include prepending list-identifying material to the Subject field, or appending URIs and such to the message body referring Receivers to further information about the list itself. This will almost always invalidate the Primary signature, so downstream receivers cannot be sure (via DKIM, at least) where the message originated. Kucherawy & Crocker Expires December 9, 2014 [Page 7] Internet-Draft DKIM-Delegate June 2014 5.1. Detecting Header Changes During the development of DKIM, consideration was given to the notion of using the "z=" tag (if present) to identify changes to the header made in transit that render a signature invalid. Ultimately it was decided that a signature should be considered invalid even if analysis of the content of "z=" could be used to confirm that the change made in transit was innocuous. The content of "z=" was meant to be used only as a debugging tool by humans. Under this use, if the Subject header field was included in the header hash, it may be useful to use "z=" (if present) to detect changes made to the Subject field, if any. If those changes appear to be trivial, such as the insertion of a prefix string at the front of the header field's original value, the Primary and/or Secondary signature could be re-attempted with the original Subject field value. If the re-attempt succeeds, the verifier could decide that this profile's requirements have been satisfied. 6. Security Considerations Use of this header field (and DKIM as described here) amounts to an ephemeral granting of the ability for the first Receivers (the Mediators named in the To and Cc fields) to generate content that the ultimate Receivers will consider valid on behalf of the Author. A compromised Mediator can thus replace the original content in its entirety while still satisfying this profile. Section 8.2 [RFC6376] discusses the risks of using "l=" tags when generating signatures. The "l=" tag and its implications were discussed at length during the development of DKIM, and its use today is not popular because it opens up the possibility of replay-type exploits where legitimate, signed messages are co-opted, modified, and then sent as spam. Use of "l=" here is advocated only for the specific use cases this document seeks to address, namely survivability of Originator signatures through modifying Mediators such as lists. It is believed that the exposure thus created is tolerable, in particular because a Mediator signature without "l=" is required for this profile to be satisfied, and the exposure created by use of "l=" in the Secondary signature is constrained by a short signature expiration time. 7. IANA Considerations IANA is requested to make the following new entry in the Permanent Message Header Field Names registry, per [RFC3864]: Kucherawy & Crocker Expires December 9, 2014 [Page 8] Internet-Draft DKIM-Delegate June 2014 Header field name: DKIM-Delegate Applicable protocol: mail ([RFC5322]) Status: Experimental Author/Change controller: IETF Specification document(s): [this document] Related information: Requesting review of any proposed changes and additions to this field is recommended. 8. References 8.1. Normative References [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. 8.2. Informative References [I-D.KUCHERAWY-DMARC-BASE] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting and Conformance (DMARC)", I-D draft-kucherawy-dmarc-base. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011. [RFC6541] Kucherawy, M., "DomainKeys Identified Kucherawy & Crocker Expires December 9, 2014 [Page 9] Internet-Draft DKIM-Delegate June 2014 Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, February 2012. Appendix A. Example [To Be Completed] Appendix B. Acknowledgments The authors wish to acknowledge Steve Atkins, Barry Leiba, (other names) for their comments during the development of this document. Authors' Addresses Murray S. Kucherawy EMail: email@example.com D. Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale 94086 USA Phone: +1.408.246.8253 EMail: firstname.lastname@example.org URI: http://bbiw.net Kucherawy & Crocker Expires December 9, 2014 [Page 10]