[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/