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


                   Delegating DKIM Signing Authority
                    draft-kucherawy-dkim-delegate-00

Abstract

   DomainKeys Identified Mail (DKIM) permits a handling agent to affix a
   digital signature to an email message, associating a domain name with
   that message using cryptographic signing techniques.  The digital
   signature typically covers most of a message's original portions,
   although the specific choices for content hashing are at the
   discretion of the signer.  DKIM signatures survive simply email
   relaying but typically are invalidated by processing through
   Mediators, such as mailing lists.  For such cases, the signer needs a
   way to indicate that a valid signature from some third party was
   anticipated, and constitutes an acceptable handling of the message.
   This enables a receiver to conclude that the content is legitimately
   from that original signer, even though its original signature no
   longer validates.

   This document defines a mechanism for improving the ability to assess
   DKIM validity for such messages.

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.

Copyright Notice




Kucherawy & Crocker     Expires December 9, 2014                [Page 1]


Internet-Draft                DKIM-Delegate                    June 2014


   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.  DKIM-Delegate Specification  . . . . . . . . . . . . . . . . .  4
     3.1.  Design Summary . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Specification  . . . . . . . . . . . . . . . . . . . . . .  4
     3.3.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Considerations for Secondary Signatures  . . . . . . . . . . .  6
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Detecting Header Changes . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Example . . . . . . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 10




















Kucherawy & Crocker     Expires December 9, 2014                [Page 2]


Internet-Draft                DKIM-Delegate                    June 2014


1.  Background

   DomainKeys Identified Mail [RFC6376] defines a mechanism whereby a
   verified domain name can be attached to a message, using a
   cryptographic signature.  It does not, however, assert that this
   domain name matches a domain name found anywhere else in the message.

   DKIM signature survival is usually successful through basic email
   relaying nodes.  It also survives simple Mediators, such as mailbox
   forwarding agents, because they only modify the message envelope and
   do not modify the original message header or body.  Transit through
   other Mediators, such as mailing lists, is usually problematic,
   because they modify portions of the message covered by the signature
   and therefore invalidate it.

   When a receiver needs to determine whether a message was legitimately
   processed by a purported original signer, a mechanism is needed that
   is more likely to survive transit through Mediators.  This need is
   especially strong for environments wishing to enforce policy linkage
   between the author, the author's domain and specific email service
   providers, such as when the latter two are the same.  An example of
   such a need is when that original signer publishes policies
   concerning the use of its domain name.  Examples are ADSP [RFC5617]
   and DMARC [I-D.KUCHERAWY-DMARC-BASE].  These policies cannot be
   applied properly when legitimate mail for the original signer's
   domain cannot be validated by the final Receiver.  The potential for
   malfunction otherwise is described in Section 5.2 of [RFC6377].

   The issues with mailing lists and similar re-mailing applications can
   be resolved by a mechanism that permits the original signer's domain
   ("A") to indicate that some other domain ("B") is explicitly
   permitted to re-sign content generated by "A", such that a Receiver
   can observe signaling from both "A" and "B" that this relationship
   exists.

   An experimental attempt to do this appeared in [RFC6541].  The method
   presented there imposes a burden on the original signing domain to
   publish those relationships a priori, via the DNS.  This proved
   cumbersome with poor scaling properties.  So, a mechanism that does
   not have such an external dependency is preferred.

2.  Definitions

   Numerous terms used here, especially "Author", "Originator",
   "Receiver", and "Recipient", are defined in [RFC5598].  DKIM-related
   terminology, such as "Signing Domain", are taken from the DKIM
   specification [RFC6376].




Kucherawy & Crocker     Expires December 9, 2014                [Page 3]


Internet-Draft                DKIM-Delegate                    June 2014


3.  DKIM-Delegate Specification

   An email header field, called "DKIM-Delegate", is defined.  When
   present, it asserts an ephemeral relationship between an original
   message signing domain and a later intermediary (Mediator).

3.1.  Design Summary

   An "Original Signer" (typically the Originator serving the Author)
   affixes two DKIM signatures to a message.  One is of the usual type,
   covering the entire message, and the second is tailored to better
   survive transit through Mediators such as authorized mailing lists.
   A DKIM-Delegate field is added to the message, to indicate that this
   mechanism is in force; this is covered by the second signature (and
   possibly, but not necessarily, the first).  Optionally, a Mediator
   also signs the message, to provide a reliable indication of handling
   by the Mediator.  If a Receiver finds that the Original Signer's
   "normal" signature does not validate or is missing, it can perform
   DKIM-Delegate evaluation.

   In combination with DKIM signatures, this mechanism can aid a
   receiver in assessing whether the message was legitimately handled by
   the intermediary and whether the message was likely to have had a
   legitimate signature by the original signing domain, even when that
   original signature became invalid.  This makes it possible to
   identify such messages separately from those without these
   assurances, and thus permits treating the latter with more
   skepticism.

3.2.  Specification

   The specific mechanism operates as follows:

   1.   A "Primary" DKIM Signature is affixed to a message by a handling
        agent, identifying the Originator's domain and using typical
        signing choices, such as covering the entire message content in
        the body hash.  (That is, it does not use the "l=" tag.)

   2.   The signer adds a DKIM-Delegate header field identifying the
        Originator's domain.  It can also identify the specific
        domain(s) with which it wishes to claim an ephemeral
        relationship; absent this indication, the list of candidate
        domains is implicit from elsewhere in the message header (see
        below).

   3.   The signer affixes a "Secondary" DKIM signature that is
        configured so as to better survive transit through the delegated
        domain(s).  The distinctive characteristic of a Secondary



Kucherawy & Crocker     Expires December 9, 2014                [Page 4]


Internet-Draft                DKIM-Delegate                    June 2014


        signature is that its hashes cover less of the message; it also
        might use more permissive canonicalization and/or have an
        especially short expiration time.  The signature MUST cover the
        DKIM-Delegate header field, in order to validate its use for the
        message.  Suggestions for details of a Secondary signature are
        discussed in Section 4.

   4.   An authorized Mediator SHOULD affix its own, normal DKIM
        signature to the message.

   5.   The Receiver attempts to validate the primary signature affixed
        by the original signer.  If it is valid, the requirements of
        this profile are satisfied (and the algorithm terminates here).

   6.   The Receiver attempts to validate the Secondary (delegation)
        signature affixed by the original signer.  If it is not valid
        (or not found), the requirements of this profile cannot be
        satisfied (and the algorithm terminates here).

   7.   The Receiver confirms that the Secondary signature header hash
        includes at least the DKIM-Delegate header field, and that the
        "d=" value in the Secondary signature matches the "d=" value in
        the DKIM-Delegate field.  If either is not true, the
        requirements of this profile cannot be satisfied (and the
        algorithm terminates here).

   8.   If the DKIM-Delegate field includes a list of domain names to
        which delegation of re-signing authority is claimed, call this
        set "D".

   9.   If the DKIM-Delegate signature does not include such a list, the
        Receiver collects all header fields that were covered by the
        header hash of the Secondary DKIM signature and that contain
        recipient addresses.  These can be found in that signature's
        "h=" tag.  The obvious examples are the To and Cc fields (if
        present).  The Receiver extracts the set of domain names from
        the collected header fields, and calls this set "D".

   10.  The Receiver performs normal validation checks of all other DKIM
        signatures on the message that include the entire message body
        in their body hashes, and stores the set of domains from passing
        signatures in set "S".

   11.  If the intersection of "D" and "S" is not empty, the
        requirements of this profile are satisfied; otherwise, the
        requirements are not satisfied.





Kucherawy & Crocker     Expires December 9, 2014                [Page 5]


Internet-Draft                DKIM-Delegate                    June 2014


3.3.  Syntax

   The content of the DKIM-Delegate header field is a tag-list as
   defined in Section 3.2 of [RFC6376].  The valid tags are:

   d= Author domain (plain-text; REQUIRED).  This value names the domain
      of the Author, which is delegating signing authority to one or
      more other domains.

   t= Delegation target (plain-text; OPTIONAL).  This value is a comma-
      separated list of domain names to which the authority to sign on
      behalf of the Author domain is being delegated.  When not present,
      this list is inferred from the domain names present in the
      recipient fields (To, Cc) of the header.

   As with DKIM itself, any other tag MUST be ignored.

4.  Considerations for Secondary Signatures

   The Secondary (delegation) signature MUST cover at least the DKIM-
   Delegate field and the visible recipient fields of the message, but
   might not cover any of the content.  Under this profile, domains that
   appear in the explicit delegation list (or are otherwise inferred
   from the recipient header fields) are permitted to alter and re-send
   the content.

   Delegated domains SHOULD sign the message.  However, receivers MAY
   accept a Secondary signature for messages lacking a delegated
   signature if the receiver can otherwise determine that the message
   was handled through a delegated domain.

   Original signers need to tailor the secondary signature to best
   survive transit through the designated Mediators.  Settling on a
   common signing profile for these delegation "tokens" is likely to
   change with experience.

   A reasonable example signature profile could cover the following
   header fields:

   o  From (required by DKIM)

   o  To and Cc (contain Receiver addresses)

   o  Message-Id (binds the signature to a specific message)

   o  Date (binds the signature to a specific date and time)





Kucherawy & Crocker     Expires December 9, 2014                [Page 6]


Internet-Draft                DKIM-Delegate                    June 2014


   o  DKIM-Delegate (signals to participating receivers that an
      ephemeral delegation of signing authority is in effect)

   Subject, though normally covered by signatures as per Section 5.4 of
   [RFC6376], can be omitted for a Secondary signature if the original
   signer anticipates legitimate alteration of it by a Mediator.  See
   also Section 5.1.

   The Secondary signature might cover the message content, but allow
   for legitimate Mediator modifications by including an "l=" tag in the
   signature.  This would require the Mediator to restict its
   alterations to involve appended content only.  Hence the Secondary
   signature can use an "l=" value reflecting the entire message as
   generated by the Author, or "0" (zero) allowing a complete
   reformatting of the message.  Obviously the latter grants the
   Mediator considerable latitude in what it will ultimately emit, while
   the former is much more constrained.  The original signer of the
   message can choose whichever is more appropriate for its own policies
   and requirements.

   This use of DKIM's "l=" value assumes messages sent to the Mediator
   that are not part of a multipart message structure, as described in
   Multipurpose Internet Mail Extensions (MIME; see [RFC2045]).  It
   might not be possible to select a practical signing length for
   messages in other than the basic message format.

   The expiration time on the Secondary signature needs to be long
   enough to permit evaluation by receivers of the re-submitted message,
   yet short enough to limit the potential for unauthorized replay
   attacks.  A good choice is a small number of days or even hours.

5.  Discussion

   The use of the Primary signature ensures that if the original message
   arrives unmodified, the Receiver is assured of its legitimacy as
   having been generated and sent by the original signer, irrespective
   of what Mediator handled it.

   Mediators, such as mailing list software, commonly make adjustments
   to a message prior to re-submitting it for transfer to final
   recipients.  Adjustments often include prepending list-identifying
   material to the Subject field, or appending URIs and such to the
   message body referring Receivers to further information about the
   list itself.  This will almost always invalidate the Primary
   signature, so downstream receivers cannot be sure (via DKIM, at
   least) where the message originated.





Kucherawy & Crocker     Expires December 9, 2014                [Page 7]


Internet-Draft                DKIM-Delegate                    June 2014


5.1.  Detecting Header Changes

   During the development of DKIM, consideration was given to the notion
   of using the "z=" tag (if present) to identify changes to the header
   made in transit that render a signature invalid.  Ultimately it was
   decided that a signature should be considered invalid even if
   analysis of the content of "z=" could be used to confirm that the
   change made in transit was innocuous.  The content of "z=" was meant
   to be used only as a debugging tool by humans.

   Under this use, if the Subject header field was included in the
   header hash, it may be useful to use "z=" (if present) to detect
   changes made to the Subject field, if any.  If those changes appear
   to be trivial, such as the insertion of a prefix string at the front
   of the header field's original value, the Primary and/or Secondary
   signature could be re-attempted with the original Subject field
   value.  If the re-attempt succeeds, the verifier could decide that
   this profile's requirements have been satisfied.

6.  Security Considerations

   Use of this header field (and DKIM as described here) amounts to an
   ephemeral granting of the ability for the first Receivers (the
   Mediators named in the To and Cc fields) to generate content that the
   ultimate Receivers will consider valid on behalf of the Author.  A
   compromised Mediator can thus replace the original content in its
   entirety while still satisfying this profile.

   Section 8.2 [RFC6376] discusses the risks of using "l=" tags when
   generating signatures.  The "l=" tag and its implications were
   discussed at length during the development of DKIM, and its use today
   is not popular because it opens up the possibility of replay-type
   exploits where legitimate, signed messages are co-opted, modified,
   and then sent as spam.

   Use of "l=" here is advocated only for the specific use cases this
   document seeks to address, namely survivability of Originator
   signatures through modifying Mediators such as lists.  It is believed
   that the exposure thus created is tolerable, in particular because a
   Mediator signature without "l=" is required for this profile to be
   satisfied, and the exposure created by use of "l=" in the Secondary
   signature is constrained by a short signature expiration time.

7.  IANA Considerations

   IANA is requested to make the following new entry in the Permanent
   Message Header Field Names registry, per [RFC3864]:




Kucherawy & Crocker     Expires December 9, 2014                [Page 8]


Internet-Draft                DKIM-Delegate                    June 2014


     Header field name: DKIM-Delegate
     Applicable protocol: mail ([RFC5322])
     Status: Experimental
     Author/Change controller: IETF
     Specification document(s): [this document]
     Related information:
         Requesting review of any proposed changes and additions to
         this field is recommended.

8.  References

8.1.  Normative References

   [RFC3864]                   Klyne, G., Nottingham, M., and J. Mogul,
                               "Registration Procedures for Message
                               Header Fields", BCP 90, RFC 3864,
                               September 2004.

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

8.2.  Informative References

   [I-D.KUCHERAWY-DMARC-BASE]  Kucherawy, M., Ed. and E. Zwicky, Ed.,
                               "Domain-based Message Authentication,
                               Reporting and Conformance (DMARC)",
                               I-D draft-kucherawy-dmarc-base.

   [RFC2045]                   Freed, N. and N. Borenstein,
                               "Multipurpose Internet Mail Extensions
                               (MIME) Part One: Format of Internet
                               Message Bodies", RFC 2045, November 1996.

   [RFC5598]                   Crocker, D., "Internet Mail
                               Architecture", RFC 5598, July 2009.

   [RFC5617]                   Allman, E., Fenton, J., Delany, M., and
                               J. Levine, "DomainKeys Identified Mail
                               (DKIM) Author Domain Signing Practices
                               (ADSP)", RFC 5617, August 2009.

   [RFC6377]                   Kucherawy, M., "DomainKeys Identified
                               Mail (DKIM) and Mailing Lists", BCP 167,
                               RFC 6377, September 2011.

   [RFC6541]                   Kucherawy, M., "DomainKeys Identified



Kucherawy & Crocker     Expires December 9, 2014                [Page 9]


Internet-Draft                DKIM-Delegate                    June 2014


                               Mail (DKIM) Authorized Third-Party
                               Signatures", RFC 6541, February 2012.

Appendix A.  Example

   [To Be Completed]

Appendix B.  Acknowledgments

   The authors wish to acknowledge Steve Atkins, Barry Leiba, (other
   names) for their comments during the development of this document.

Authors' Addresses

   Murray S. Kucherawy

   EMail: superuser@gmail.com


   D. Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net
   URI:   http://bbiw.net























Kucherawy & Crocker     Expires December 9, 2014               [Page 10]