Network Working Group M. Kucherawy Internet-Draft April 5, 2015 Intended status: Experimental Expires: October 7, 2015 Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures draft-kucherawy-dkim-transform-00 Abstract DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations, so that a verifier might rewind such a modification and thereby confirm that the signature still verifies against the original content. 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 October 7, 2015. Kucherawy Expires October 7, 2015 [Page 1]
Internet-Draft DKIM Transformations April 2015 Copyright Notice Copyright (c) 2015 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. The 'tf' DKIM Signature Tag . . . . . . . . . . . . . . . . . 4 4. DKIM Operational Flow . . . . . . . . . . . . . . . . . . . . 4 4.1. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. The 'mimeify' Transformation . . . . . . . . . . . . . . . . . 6 6. The 'add-part' Transformation . . . . . . . . . . . . . . . . 7 7. The 'mime-wrap' Transformation . . . . . . . . . . . . . . . . 8 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9.1. Imported from DKIM . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. DKIM Transformations Registry . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix C. To-Do List . . . . . . . . . . . . . . . . . . . . . 11 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Kucherawy Expires October 7, 2015 [Page 2]
Internet-Draft DKIM Transformations April 2015 1. Background DomainKeys Identified Mail (DKIM) [RFC6376] defines a mechanism whereby a verified domain name can be attached to a message, or portion of a message, using a cryptographic signature. It presents two possible schemes for converting the header block to a canonical form, and similarly two schemes for canonicalizing the body. In each case, one scheme permits no changes whatsoever, and the other permits limited changes restricted to areas such as whitespace munging, case changing, and header field wrapping. Some agents deliberately, but innocently, modify content in transit. A prime example of this is mailing lists, which might add a prefix to the Subject field of a message, add list-specific information to the header (in the form of new header fields), or append administrivia to the body of messages before they are re-mailed to the list subscribers. Use of mailing lists with respect to DKIM, and a discussion of related challenges, can be found in [RFC6377]. The urgency to solve this family of problems increased dramatically with the large-scale introduction of Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. There is a desire to have DKIM signatures survive transit through lists. One way to do this is to make use of DKIM's "l=" tag which limits the portion of the body that is signed. This exposes an attack vector, however, since one can simply append any content to a partly-signed message and the signature will continue to verify. (See Section 8.2 of [RFC6376].) This document defines an incremental mechanism to declare that a signature is being applied to message content after one of a small set of well-defined, reversible, content transformations. The message verifier can then reverse the effect of the claimed transformation and, theoretically, recover the original content and confirm its integrity. The utility of this mechanism is predicated on the notion that agents that modify signed messages will do so in one of the known (registered) transformations, and that common transformations will be registered as they are developed. 2. Definitions Numerous terms used here, especially "Author" and "Mediator", are defined in [RFC5598]. Kucherawy Expires October 7, 2015 [Page 3]
Internet-Draft DKIM Transformations April 2015 3. The 'tf' DKIM Signature Tag This section defines the 'tf' DKIM signature tag. The presence of this tag is an indication to a verifier that the agent adding this signature transformed the original message between receipt (and verification of any previously-applied signature) and retransmission, and that such transmission was one of a set that are common, well-defined, and reversible. The value of this tag is one of the transformations registered in the DKIM Message Transformations registry. See Section 10. Using ABNF, as defined in [RFC5234]: sig-tf-tag = %x74.66 [FWS] "=" [FWS] sig-tf-tag-trans sig-tf-tag-trans = Token ; expected to be a transformation name found ; in the DKIM Message Transformations ; registry "Token" is imported from [RFC2045], and "FWS" is imported from [RFC6376]. A verifier finding a signature with the "tf" tag present but bearing a value it does not recognize ignores its presence (other than including it in hash computation). 4. DKIM Operational Flow In all cases, DKIM operations involving this tag begin with a message author generating content and submitting it to the appropriate Message Submission Agent (MSA). The MSA is presumed to have some kind of DKIM signature generation capability, and thus the message will have an author domain signature attached to it. When a message arrives at a Mediator or other intermediary that wishes to distribute an altered form of the author's content, such as a Mailing List Manager (MLM) configured to do so, it generates an additional DKIM signature with the new form of the content as input. This second includes the "tf" tag, announcing which known transformation was applied to the message prior to creation of the Mediator's signature. Importantly, the original signature is not removed from the message nor is it altered in any way. Since DKIM-compliant verifiers ignore signature tags of which they are not aware, this is a purely incremental change as it will not interfere with the deployed DKIM infrastructure. Kucherawy Expires October 7, 2015 [Page 4]
Internet-Draft DKIM Transformations April 2015 A DKIM verifier aware of this tag will first confirm that the Mediator's signature is valid. On doing so, it can then apply the reverse of the claimed transformation. This will restore the message to the form and content originally submitted by the Author, and the Author's signature will then be valid over the restored content. This might be used to confirm that a message which passed through a Mediator can still be considered to have a valid Author signature, satisfying policy checks such as those described in [RFC7489]. 4.1. Detail 1. Author A generates message M, addressed to recipient R, which is a Mediator (a mailing list manager, for example). 2. Author submits M to its MSA. 3. MSA generates and attaches DKIM signature S(M), and sends the message toward its destination, which is the servers accepting messages for R. 4. The message arrives at R. R might verify signature S(M) and apply any local policy if the verification fails. 5. R selects one of the registered, reversible transformations, T, to be applied to M. (The reverse operation will be called T'.) R thus generates T(M) as the new content. The new content necessarily includes S(M). 6. R also generates a signature of T(M), which is S(T(M)). This new signature includes the "tf" tag defined above, identifying the transformation T that was used in the previous step. It then sends the message toward its final destination(s). For a mailing list manager, this would be all of the current list subscribers. 7. The Mediator version of the message arrives at ultimate recipient Z. Assuming no unexpected damage to the message in transit, Z will be able to validate S(T(M)). 8. If the verifier is not aware of this tag and its meaning, or if the verifier is not aware of how to reverse the identified transformation, normal DKIM verification continues from here, and this modified algorithm terminates. It would be expected that S(T(M)) would be valid, but S(M) would not. 9. The compliant verifier applies T' to the validated message content. By definition, T'(T(M)) is M. Since the Mediator preserved Author signature S(M), the verifier can now attempt to Kucherawy Expires October 7, 2015 [Page 5]
Internet-Draft DKIM Transformations April 2015 validate the Author signature against the recovered original content. 5. The 'mimeify' Transformation The "mimeify" transformation converts a message that is not formatted according to Multipurpose Internet Mail Extensions (MIME) [RFC2045], and converts it to that form. This allows a Mediator to place the original content in one MIME part, and its own additional content in a second MIME part. The reverse transformation is to remove the second MIME part altogether, and then strip away all MIME structure, leaving only the original author content. More specifically, the transformation follows these steps: 1. A "MIME-Version" header field is added, as described in [RFC2045]. 2. A "Content-Type" header field is added, also as described in [RFC2045]. The media type is "multipart/mixed". A unique compliant boundary is also generated. 3. Two MIME parts are created. The first MIME part is of type "text/plain", and contains the body of the original message. The second MIME part contains whatever content the Mediator is configured to add, and uses a media type appropriate to that content. 4. The body of the message is replaced with the following, in a manner compliant with [RFC2045], namely: A. the boundary; B. an optional "Content-Type" header field indicating the original content used the default "text/plain" media type, and the optional "charset" parameter; C. a line break; D. the body of the original message; E. a line break; F. the boundary; G. any MIME header fields needed to introduce the content the Mediator wishes to add; Kucherawy Expires October 7, 2015 [Page 6]
Internet-Draft DKIM Transformations April 2015 H. a line break; I. the Mediator's content; J. the terminating boundary. The reverse of this transformation is as follows: 1. Extract the full content of the first MIME part. 2. Discard the entire message body, and replace it with the extracted content above. 3. Remove the "Content-Type" and "MIME-Version" header fields. 6. The 'add-part' Transformation The "add-part" transformation augments a multipart message that is already formatted according to MIME by appending an additonal part that includes the content the Mediator wishes to add. This transformation cannot be used unless the media type of the message as a whole (the one named in the Content-Type field in the header of the message itself) is "multipart/mixed". Simply put, a new part within the existing set of parts is added at the end, containing the Mediator's content. More specifically, the transformation follows these steps: 1. Determine the MIME boundary used to separate parts, found in the top-level Content-Type header field. 2. At the point of the terminating boundary in the original message, insert a non-terminating instance of the same boundary. 3. After the new boundary, write any MIME fields needed to introduce the content the Mediator wishes to add. 4. Insert a line break, followed by the Mediator's content, and an additional line break. The reverse of this transformation is as follows: 1. Locate the last instance of the boundary found in the Content- Type header field of the message itself. 2. Delete the content from that point in the message until the terminating instance of the boundary. Kucherawy Expires October 7, 2015 [Page 7]
Internet-Draft DKIM Transformations April 2015 7. The 'mime-wrap' Transformation The "mime-wrap" transformation augments a message that is already formatted according to MIME by enclosing the existing MIME structure in a new layer. This new layer contains two parts: the original MIME structure in its first part, and the Mediator content in its second part. More specifically, the transformation follows these steps: 1. Remove the Content-Type header field from the message. 2. Generate a new Content-Type header field, compliant with [RFC2045], with media type "multipart/mixed", and a boundary. 3. The body of the message is replaced with the following, in a manner compliant with [RFC2045], namely: A. the new boundary; B. the previously deleted Content-Type header field; C. a line break; D. the entire original content of the message; E. a line break; F. the new boundary; G. any MIME header fields needed to introduce the content the Mediator wishes to add; H. a line break; I. the Mediator's content; J. the terminating instance of the new boundary. This leaves the new message as a MIME message with two parts at the outermost layer; the original message appears as the first part, and the Mediator's content is the second part. The reverse of this transformation is as follows: 1. Extract the Content-Type header field from the first MIME part in the message. This appears immediately after the first MIME boundary in the message. Kucherawy Expires October 7, 2015 [Page 8]
Internet-Draft DKIM Transformations April 2015 2. Replace the Content-Type header field of the message with the one extracted above. 3. Extract the content of the first MIME part in the message. This appears between the first two instances of the outermost MIME boundary. 4. Replace the entire message body with the extracted MIME part. 8. Discussion Section 3.5 of [RFC6376] defined an optional DKIM signature tag ("z=") that can be used to reconstruct the header field set that was signed by the author. When a signature fails to verify, this information could conceivably be used to replay the correct (original) header fields through canonicalization and possibly yield a passing result. Doing this augmented replay blindly would allow a signature to pass when it failed because some alteration correctly rendered the original content invalid or even dangerous. This is manifestly not an error. Identifying which mutations of the original content ought to be permissible necessarily relies on heuristics and possibly local knowledge. However, a mutation universally considered to be tolerable should become part of the canonicalization process rather than being identified and handled in this manner. Moreover, if two implementations apply different heuristics, the result of verification is no longer deterministic. As a result, [RFC6376] asserts that use of the "z=" content, if present, can only be used for diagnostic purposes. In contrast, the proposal here enumerates a handful of specific mutations known to be safe, and in common use, that are also reversible, which means the Author's original content can be unambiguously recovered and subjected to the usual signature verification process even though the message has been legitimately modified by a Mediator. 9. Security Considerations 9.1. Imported from DKIM Section 8 of [RFC6376] discusses numerous security considerations relevant to DKIM. Of particular interest here is Section 8.2, which discusses concerns regarding signatures that sill verify in the presence of added message content. Kucherawy Expires October 7, 2015 [Page 9]
Internet-Draft DKIM Transformations April 2015 10. IANA Considerations 10.1. DKIM Transformations Registry IANA is requested to create a new registry in the DomainKeys Identified Mail (DKIM) Parameters group called the "DKIM Transformations Registry". This registry will enumerate known reversible content transformations that might be made by Mediators to messages bearing DKIM signatures. Entries in this registry include all of the following: Name: A simple name for a reversible message transformation; Description: A terse description for the transformation; Specification: A reference to a stable specification in which this transformation and its inverse are clearly described; Status: Must be one of: * "active", meaning the transformation is in current use; * "deprecated", meaning the transformation is not in current use. An entry may be added or updated in this registry only when it meets the requirements of the "Specification Required" rules found in [RFC5226]. The Designated Expert will confirm that the referenced specification is clear and complete, and that the transformation and its inverse are not ambiguous. The initial entries in this registry are as follows, all with status "active": add-part: Defined in Section 6 of this document. The simple description is "append an extra text MIME part to a MIME-formatted message". mime-wrap: Defined in Section 7 of this document. The simple description is "wrap a MIME-formatted message in a new multipart layer". mimeify: Defined in Section 5 of this document. The simple description is "convert a non-MIME message to a MIME message". 11. References Kucherawy Expires October 7, 2015 [Page 10]
Internet-Draft DKIM Transformations April 2015 11.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. 11.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011. [RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, March 2015. Appendix A. Examples TODO: Show at least one example. Appendix B. Acknowledgements The original team developing this concept included Michael Adkins and Wez Furlong. The author wishes to acknowledge (names) for their comments during the development of this document. Appendix C. To-Do List o Examples. Kucherawy Expires October 7, 2015 [Page 11]
Internet-Draft DKIM Transformations April 2015 Appendix D. Change Log 00: Initial revision. Author's Address Murray S. Kucherawy EMail: superuser@gmail.com Kucherawy Expires October 7, 2015 [Page 12]