Lenient DKIM
draft-vanrein-dkim-lenient-00

Versions: 00                                                            
Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                      September 25, 2017
Expires: March 29, 2018


                              Lenient DKIM
                     draft-vanrein-dkim-lenient-00

Abstract

   DKIM is a framework for signed messages, especially for email.  While
   in transit, changes are sometimes made, and these break the DKIM-
   Signature.  This specification makes DKIM more lenient, without
   changes to its core.  It adds leniency towards MIME body rewrites,
   removal of alternatives and annotation with bits of text.  The
   intention is to allow these changes such that they can be clearly
   shown to the user, while indicating that the remainder of the
   signedmessage is still in tact.

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 https://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 March 29, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (https://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



Van Rein                 Expires March 29, 2018                 [Page 1]


Internet-Draft                Lenient DKIM                September 2017


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Annotating DKIM-Signed-Content  . . . . . . . . . . . . . . .   3
     2.1.  Header Definition . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Signing MIME bodies . . . . . . . . . . . . . . . . . . .   5
   3.  Canonicalisation for MIME Content . . . . . . . . . . . . . .   5
     3.1.  MIME headers  . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  MIME body parts . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   DKIM standardises a header that signs content and headers of (email)
   messages.  This is a practical system to validate (the origin of) a
   message to not have changed; unfortunely however, it breaks on a few
   patterns of communication that are in common use xref-
   target-"RFCnnnn".  As a result, it is difficult to assign the full
   weight of evidence that DKIM could otherwise provide.

   DKIM signs content based on their wire format, which may include a
   transfer-encoding when the MIME extensions are used.  MTAs may have
   to alter this transfer-encoding to accommodate a downgrade of
   communication capabilities, and are therefore permitted to do so, but
   this is not compatible with current DKIM.  This specification
   introduces a new canonicalisation algorithm to remedy this problem,
   based on fixating the binary content of a MIME body part.

   Another common practice is the introduction of extra text in the
   Subject header of an email, or in the body or body parts.  As a
   general principle, it need not be problemtic to introduce extra data
   to an email, as long as this is clearly shown in the MUA.  Given that
   email is usually rendered in a manner that has information fields in
   clearly distinct graphical framing, it should be possible for a MUA
   to unambiguously mark any additions made.  This specification
   introduces a manner of locating the parts of a message that were not
   modified since it was signed, and leaves it to the MUA to decide on a
   method of distinct rendering for original and modified parts.  The
   same mechanisms may be useful for MTAs for distinguishing common
   patterns from abusive ones.  When unsupportive or incapable, a MUA or




Van Rein                 Expires March 29, 2018                 [Page 2]


Internet-Draft                Lenient DKIM                September 2017


   MTA is always free to not incorporate DKIM's confirmations of message
   content.

   A more debatable practice is the removal of complete MIME
   attachments.  This is sometimes done for content in an undesirable
   format, usually for operational considerations.  Such removals can be
   clearly marked, and it is up to the MUA whether to accept the
   removal.  When one part of an originally sent multipart/alternative
   is removed, it may not be as bad as when the composition is altered,
   as would be the case with other multipart types, such as multipart/
   form-data.

   The general handling of a MIME multipart/* message body involves a
   number of independently encoded body parts.  When this Content-Type
   is used, a separate DKIM-Signature will be made on each of the body
   parts, and a dedicated canonicalisation method will be used to
   compose the parts.  This will list the hashes of the various body
   parts, thus enabling the detection of a removed part.

2.  Annotating DKIM-Signed-Content

   When changes are made to parts of the message, be it to headers or
   body, then a DKIM-Signature is invalidated.  Although this is a clear
   sign of modification, it is not always a sign of a rogue change.
   Ideally, the changed content would be presented to the user, but in
   such a manner that original content can be easily distinguished from
   changed content.  When the changed message is subsequently signed by
   an intermediate mailer, it is also clear where any concerns about the
   change should be redirected, which is helpful for reputation
   management.

   The DKIM-Signed-Content header can be inserted after a DKIM-
   Signature, possibly at the origin or at a later stage of the message,
   to mark parts of the message that are incorporated into the signature
   as a whole header, or as a whole body.  It may in turn be
   incorporated into a DKIM-Signature of a modified-forwarding party
   such as an email list, where the new DKIM-Signature implies taking
   responsibility over the changes made locally.  But even when this is
   not done, the DKIM-Signed-Content header allows a receiving MTA, MUA
   or user to learn standard patterns of change by such intermediates,
   and hopefully trigger alarms after deviations from a pattern.

   To detect extra text, the DKIM-Signed-Content header describes the
   range that was originally signed, describing the text in canonical
   representation through its size, a rolling checksum and a secure
   hash.  The size and rolling checksum can be used to quickly pass
   through a text in search of the original text; the secure hash is
   then used to validate that it is indeed a good match.



Van Rein                 Expires March 29, 2018                 [Page 3]


Internet-Draft                Lenient DKIM                September 2017


   Originators could insert DKIM-Signed-Content headers before or after
   inserting the DKIM-Signature header to allow non-compliant forwarders
   to be easily recognised.  Forwarders who add their own DKIM-Signature
   on modified content are advised to retain the existing ones, validate
   or remove any DKIM-Signed-Content headers inserted after the last
   DKIM-Signature, add any missing DKIM-Signed-Content headers over what
   will be modified, then make the desired modifications and then insert
   the new DKIM-Signature header.  This procedure ensures that the
   forwarder only takes responsibility over their own work, which helps
   in building their reputation.

   DKIM-Signature and DKIM-Signed-Content headers MUST be inserted on
   top of the message, and MUST NOT be reordered in transit.  This is a
   common and reasonable requirement for current messaging systems.

   The DKIM-Signed-Content header works for complete headers or for
   complete bodies, and will fail to work when content is being removed.
   This is to protect users from information being held back; the one
   exception is in the handling of multipart/alternative, defined below.

2.1.  Header Definition

   The DKIM-Signed-Content header consists of one or more sets of the
   following four components, with whitespace to separate components:
   (1) the path to the content; (2) the decimal notation for the length
   in bytes; (3) the hexadecimal notation for a rolling hash; (4) the
   secure hash of the content.

   The path to the content is either a header name or the special word
   "Body" to notify the message body.  When multiple instances exist, an
   optional extension is permitted, namely a colon and a decimal
   sequence number, counting from 0.  Headers count in the order of
   insertion, so in the opposite order of their occurrence in the
   message.  Bodies count in the order in which they occur in th
   message, but this is only meaningful for multipart MIME-types.
   TODO:ALT:0 is the last value inserted before the DKIM-Signature; no
   going back.  TODO:EXT:Allow header:index:header:index:...

   The values that follow all apply to the canonical form of the
   information, be it a header or body, as specified in the "c"
   parameter of the DKIM-Signature that was last inserted into the
   message.

   The rolling hash is TODO:AS_IN_RSYNC? cyclic polynomials looks best.
   Implementation note: either have the full message in memory or have
   to files open on it for reading.





Van Rein                 Expires March 29, 2018                 [Page 4]


Internet-Draft                Lenient DKIM                September 2017


   The secure hash matches the representation and algorithm of the "bh"
   field in the related DKIM-Signature.

2.2.  Signing MIME bodies

   When a body with MIME content is signed, then more headers should be
   considered for inclusion in the DKIM-Signature; notably, MIME-
   Version, Content-Type, Content-Disposition SHOULD be included; on the
   other hand, Content-Transfer-Encoding SHOULD NOT be included when the
   intention is to support changes to the transfer encoding.  When
   headers are absent, their inclusion into the DKIM-Signature header
   list disables later-on addition of these headers.  TODO:CHECK

   Special processing is required for the Content-Type header; it
   includes a field named boundary, whose contents MUST be set to an
   empty string, included in double quotes, before computing the header
   checksum.  This assures that changes to the boundary tag are
   permitted while the message moves between MTAs.  TODO:ALT: Move this
   parameter to the end of the header and take it out from the DKIM-
   Signed-Content as well as the DKIM-Signature; this requires MTAs and
   MUAs to recognise this missing information as correctly absent.

   All body parts of a multipart MIME message SHOULD have a DKIM-
   Signature inserted.  In this case, the Content-Type, Content-
   Disposition and Content-ID headers SHOULD be included, even when they
   are not presented as headers, in which case they could not be added
   later.  Note that the remarks made above for the boundary tag in a
   Content-Type header may apply recursively.

   When signing a multipart message, a DKIM-Signed-Content header SHOULD
   include the DKIM-Signature headers of the directly subordinate body
   parts.  Indirect subordinates are included recursively by these
   nested DKIM-Signature headers.

   This practice enables the detection of removed as well as added body
   parts.  A common example is the removal of a text/html form from
   multipart/alternative, so as to leave the text/plain form.  This may
   be tolerated on account of the semantics of multipart/alternative
   messages.

3.  Canonicalisation for MIME Content

   MIME messages require special handling.  The descriptions below
   define how headers and bodies are canonicalised for MIME handling.
   When a message has a MIME-Version header, it MAY want ot use c=mime/
   mime in its DKIM-Signature headers.





Van Rein                 Expires March 29, 2018                 [Page 5]


Internet-Draft                Lenient DKIM                September 2017


   This is an extension to the version of DKIM that is currently in use,
   but it is not a change to the header format, merely a matter of new
   canonicalisation rules and handling for contained body parts.  This
   means that no new version number is defined for DKIM.  The changes
   may however lead to interpretation problems in older software.  To
   serve these somewhat, it is possible for DKIM signers to add not only
   a DKIM-Signature with c=mime/mime, but also with other
   canonicalisation mechanisms.  It is advised to plan a final date for
   any such policy.

3.1.  MIME headers

   Header canonicalisation for MIME headers is a modified form of the
   relaxed algorithm.  Its added function is to change any boundary tag
   in a Content-Type header to an empty string, denoted as two double
   quotes.

3.2.  MIME body parts

   When an MTA carries a binary message over a degraded link, it may
   need to change the encoding of the message body.  The simple and
   relaxed canonicalisation algorithms both relate to the wire format of
   the message and will break on such valid changes of form.  For MIME
   body parts however, this wire format is representative of an exactly
   reproduced binary format, which can serve as a canonical format for
   these body parts.

   The body canonicalisation algorithm "mime" is used to reduce the wire
   format of a MIME message body to the binary content that it
   represents, before applying hashing and signing algorithms.  This
   should make it neutral to changes to the transfer encoding.  Note
   that it is vital that the Message-Transfer-Encoding header MUST NOT
   be included in the header list when the "content" algorithm is used.

   The "mime" algorithm MUST NOT be used on multipart messages.  For
   those, an zero-byte body is used with headers including a DKIM-
   Signed-Content header that references that various body parts
   individually.

   Some MIME body parts include an URI reference, and it is possible for
   an MDA or MUA to replace a body part with such a reference to an
   external store.  In such cases, a DKIM-Signature on the body part is
   bound to fail; it would however serve to validate the downloaded
   content together with the descriptive headers that are signed along
   with it.  This means that components of the mail system that replace
   a body part by an URI reference should try to retain any DKIM-
   Signature header.  Especially when a bh field is included, it would
   be easy to verify a downloaded body part.



Van Rein                 Expires March 29, 2018                 [Page 6]


Internet-Draft                Lenient DKIM                September 2017


4.  IANA Considerations

   TODO:REGISTER:HEADER:DKIM-SIGNED-CONTENT

   TODO:REGISTER:DKIMCANONALG:CONTENT

5.  Security Considerations

   TODO: Parts before/after MIME body parts

   TODO: Modified MIME separators that also appear in body parts.

Appendix A.  Acknowledgements

Author's Address

   Rick van Rein
   ARPA2.net
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl




























Van Rein                 Expires March 29, 2018                 [Page 7]