Lenient DKIM
draft-vanrein-dkim-lenient-00

Document Type Active Internet-Draft (individual)
Last updated 2017-09-25
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text