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

Versions: 00 01

Network Working Group                                       M. Kucherawy
Internet-Draft                                              June 7, 2014
Intended status: Experimental
Expires: December 9, 2014


   A List-safe Canonicalization for DomainKeys Identified Mail (DKIM)
                   draft-kucherawy-dkim-list-canon-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
   structured message such as conversion between transfer encodings or
   addition of new message parts.  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 generating a canonicalization
   that can allows easy detection of modified content while still being
   valid for the content it originally signed.  It also presents a use
   profile of DKIM that takes advantage of this capability.

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.




Kucherawy               Expires December 9, 2014                [Page 1]


Internet-Draft         DKIM List Canonicalization              June 2014


Copyright Notice

   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.  The 'list' Canonicalization Description . . . . . . . . . . . . 3
     3.1.  Preparing Content . . . . . . . . . . . . . . . . . . . . . 4
   4.  'The 'lh=' Signature Tag  . . . . . . . . . . . . . . . . . . . 5
   5.  Use Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Imported from DKIM  . . . . . . . . . . . . . . . . . . . . 6
     6.2.  Added Content May Not Be Safe . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  DKIM-Signature Canonicalization Body Registry . . . . . . . 7
     7.2.  DKIM-Signature Tag Specifications Registry  . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . . . 7
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . . . 8

















Kucherawy               Expires December 9, 2014                [Page 2]


Internet-Draft         DKIM List Canonicalization              June 2014


1.  Background

   DomainKeys Identified Mail [RFC6376] (DKIM) 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].

   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 a new body canonicalization for DKIM that
   includes a partial signature for each message part in a message
   structured using Multipurpose Internet Mail Extensions (MIME; see
   [RFC2045]).  This allows a clear delineation between the author-
   generated content (which would be signed by the author) and content
   added downstream (which would be signed by the other actor).  A DKIM
   verifier can then determine whether the author-generated content is
   intact, and then identify and verify the content that was added
   later.

   The utility of this mechanism is predicated on the notion that agents
   that modify signed messages will do so in ways compatible with MIME.

2.  Definitions

   Numerous terms used here, especially "Author", are defined in
   [RFC5598].

3.  The 'list' Canonicalization Description

   This section defines the 'list' body canonicalization algorithm.




Kucherawy               Expires December 9, 2014                [Page 3]


Internet-Draft         DKIM List Canonicalization              June 2014


   Put simply, the list canonicalization constructs a hash tree of the
   MIME structure of the message after each part has been decoded (for
   those with a Content-Transfer-Encoding field).  The hash used is
   implied by the signature algorithm to be used (see the DKIM "a="
   tag).  Each of the hashes can be made a part of the signature to
   allow for more precise part validation, and identification of added
   content.

3.1.  Preparing Content

   A message is prepared for canonicalization by applying the following
   steps in order:

   1.  Create an empty tree.  Each node of the tree includes the
       following components:

       A.  The MIME type and subtype of the part, expressed as would be
           found in a Content-Type header field, with no whitespace or
           comments;

       B.  The unencoded content represented by the MIME part at this
           node;

       C.  A series of octets that will contain a hash of the content;

       D.  A series of zero or more pointers to other (child) nodes.

   2.  If the message is not encoded using MIME, insert a node at the
       root of the tree using a type/subtype of "text/plain" and the
       full body content.  The hash is not initialized.

   3.  If the message is encoded using MIME, then the tree is populated
       in a way that mirrors the MIME structure of the message.  In
       particular, the outermost MIME object will appear at the root
       node, and the only nodes that have children are those with a MIME
       type of "multipart".  The hashes are not initialized.

   4.  For each leaf node, compute a hash of the content of that node.
       Store the hash in the node.

   5.  For each non-leaf node, if all of its child nodes now have
       computed hashes, concatenate the hashes (with order preserved),
       and compute and store a hash of the concatenation.

   6.  Repeat the previous step until all hashes in the tree have been
       populated.

   When this canonicalization is in use, the "bh=" tag will contain the



Kucherawy               Expires December 9, 2014                [Page 4]


Internet-Draft         DKIM List Canonicalization              June 2014


   hash stored at the root of the tree.  The processes for signing and
   verification are otherwise unchanged.

4.  'The 'lh=' Signature Tag

   A signer can include an "lh=" tag, defined here, to make more than
   just the root hash information available to verifying agents.  This
   permits identification of the specific part of the MIME structure
   that was modified, added or removed by an intermediary.

   The "lh=" tag is constructed by performing an in-order traversal of
   the canonicalization tree described in Section 3.1.  At each node,
   each of the following is output, separated by a colon character
   (ASCII 0x3A):

   1.  A base64 expression of the hash at that node;

   2.  The MIME type of that node;

   3.  An integer expression of the number of children at that node.

   Between each node's output, a comma character (ASCII 0x2C) is output.

   Reconstruction of the MIME tree can be accomplished by the following
   steps:

   1.   Create a tree "T" containing a single empty node.

   2.   Create an empty node queue, "Q".

   3.   Create an information queue "I", containing the sequence of node
        information fields found in the "lh=" tag.

   4.   Select the root node of the tree.  Call this node "N".

   5.   Extract the first batch of node information ("B") from the "lh="
        tag.

   6.   Store the hash and MIME type from "B" into "N".

   7.   Enqueue the specified number of empty nodes into "Q", and attach
        them all as children of "N".

   8.   If "I" and "Q" are both empty, terminate.  If one is empty and
        the other is not, an error has occurred.

   9.   Extract the next batch of node information from "I", as "B".




Kucherawy               Expires December 9, 2014                [Page 5]


Internet-Draft         DKIM List Canonicalization              June 2014


   10.  Dequeue the next node from "Q", as "N".

   11.  Return to step 6.

   By comparing the hashes in and structure of this tree to those in the
   canonicalized tree, a receiver can identify parts of the tree (or
   entire subtrees) that have been modified.  Parts not covered by the
   signature can also be identified.

5.  Use Profile

   The intended use of this mechanism is to affix two DKIM signatures to
   a message.  The first signature is added by the Author, and
   canonicalizes the original message in its entirety.  The second
   signature is added by a modifying intermediary, such as a mailing
   list manager (MLM).

   When verifying, the Author signature on an unmodified message would
   pass verification.  For a modified message, in the typical case, the
   verification step would observe that the Author signature failed but
   the intermediary's signature verified.  When the "lh=" tag is
   present, it is possible to reconstruct the MIME structure of the
   signed message and compare it to that of the received message,
   including hashes of the content seen by each party.  By comparing
   hash values at each node of the MIME structures, it is possible to
   determine in which MIME parts changes were made and/or new parts
   added or removed by the intermediary.  The verifying agent can then
   determine whether those changes are acceptable before allowing the
   message to continue toward delivery.

6.  Security Considerations

6.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.

6.2.  Added Content May Not Be Safe

   When the use profile described in Section 3 is applied, it is
   important to note that the added content was not signed by the Author
   domain, but only by the domain of the intermediary.  Operators that
   might grant preferential handling based on valid DKIM signatures from
   favorable domains; assuming that appended content in the presence of
   such signatures does not mean the appended content is necessarily
   safe.



Kucherawy               Expires December 9, 2014                [Page 6]


Internet-Draft         DKIM List Canonicalization              June 2014


7.  IANA Considerations

7.1.  DKIM-Signature Canonicalization Body Registry

   IANA is requested to add the following entry to the DKIM-Signature
   Canonicalization Body Registry:

     Type: list
     Reference: [this document]
     Status: active

7.2.  DKIM-Signature Tag Specifications Registry

   IANA is requested to add the following entry to the DKIM-Signature
   Tag Specifications Registry:

     Type: lh
     Reference: [this document]
     Status: active

8.  References

8.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.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
              September 2011.

8.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.

Appendix A.  Examples

   TODO: Show a few examples of the conversion between some different
   MIME structures, the hash tree, and the "lh=" tag's value.







Kucherawy               Expires December 9, 2014                [Page 7]


Internet-Draft         DKIM List Canonicalization              June 2014


Appendix B.  Acknowledgements

   The original idea was proposed by Ned Freed.

   The authors wish to acknowledge (names) for their comments during the
   development of this document.

Author's Address

   Murray S. Kucherawy

   EMail: superuser@gmail.com







































Kucherawy               Expires December 9, 2014                [Page 8]


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