Network Working Group                                       M. Kucherawy
Internet-Draft
Intended status: Experimental                                 D. Crocker
Expires: October 12, 2015                    Brandenburg InternetWorking
                                                          April 10, 2015


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

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 October 12, 2015.

Copyright Notice




Kucherawy & Crocker     Expires October 12, 2015                [Page 1]


Internet-Draft                DKIM-Delegate                   April 2015


   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.  DKIM-Delegate Specification  . . . . . . . . . . . . . . . . .  4
     3.1.  Design Summary . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.3.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Preparation  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.5.  Verification . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Expiration . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Example . . . . . . . . . . . . . . . . . . . . . . .  9
   Appendix B.  To-Do List  . . . . . . . . . . . . . . . . . . . . . 10
   Appendix C.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11


















Kucherawy & Crocker     Expires October 12, 2015                [Page 2]


Internet-Draft                DKIM-Delegate                   April 2015


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 October 12, 2015                [Page 3]


Internet-Draft                DKIM-Delegate                   April 2015


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 a DKIM signatures to a message using whatever parameters it
   wishes.  In addition to this, it affixes a DKIM-Delegate field that
   indicates an ephemeral relationship exists between the Author domain
   and some set of other domains that are expected to handle the
   message.  Preferably, the Mediator also signs the message, to provide
   a reliable confirmation of handling by that Mediator.  If a Receiver
   finds that the Original Signer's "normal" signature does not validate
   or is missing, it can perform DKIM-Delegate evaluation.

   The DKIM-Delegate field includes a hash and a cryptographic
   signature, just like DKIM-Signature fields do.  However, the only
   content covered by the hash is the DKIM-Delegate field and its
   parameters.

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

   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 also identifies the specific domain(s)
        with which it wishes to claim an ephemeral relationship.  The
        DKIM-Delegate field is self-signed, as described below.

   3.   The Originator transmits the message to the Receiver in the
        usual way.



Kucherawy & Crocker     Expires October 12, 2015                [Page 4]


Internet-Draft                DKIM-Delegate                   April 2015


   4.   If the Receiver is not a Mediator, then normal DKIM processing
        occurs, and DKIM-Delegate is ignored.

   5.   An authorized Mediator SHOULD affix its own, normal DKIM
        signature to the message after making any content modifications
        it is configured to make and before re-sending the message to
        new Receiver(s).

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

   7.   The new Receiver attempts to validate the DKIM-Delegate field
        affixed by the original signer.  If it is not valid, expired, or
        absent, the requirements of this protocol cannot be satisfied
        (and the algorithm terminates here).

   8.   The Receiver extracts the list of domains authorized to re-sign
        for the Author domain from the "t=" tag of the DKIM-Delegate
        field.  Call this set "D".

   9.   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".

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

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:

   a= Signature algorithm (plain-text; REQUIRED).  As in Section 3.5 of
      [RFC6376], this contains a string that describes the signature
      generation algorithm used by the signer.

   b= Signature data (base64; REQUIRED).  As in Section 3.5 of
      [RFC6376], this contains a digital signature of the content of
      this header field.  The same syntax rules for DKIM signatures
      apply here.







Kucherawy & Crocker     Expires October 12, 2015                [Page 5]


Internet-Draft                DKIM-Delegate                   April 2015


   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.

   s= Selector name (plain-text; REQUIRED).  As in Section 3.5 of
      [RFC6376], this names a particular public/private key pair that is
      used to sign and verify the content of this header field.  It will
      be used to construct a DNS query for a text representation of the
      public key.

   t= Delegation target (plain-text; REQUIRED).  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.

   x= Expiration time (plain-text unsigned decimal integer; RECOMMENDED,
      default is no expiration) As in Section 3.5 of [RFC6376], this
      specifies a timestamp beyond which this header field MAY be
      considered invalid.

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

3.4.  Preparation

   The content of a DKIM-Delegate field is prepared for signing by
   applying the "relaxed" header canonicalization scheme defined in
   Section 3.4.2 of [RFC6376] and the algorithm described in Section
   3.7.  For DKIM-Delegate, the only content that is hashed is the
   constructed DKIM-Delegate field itself, with an empty "b=" tag;
   notably, there is no "v=" or "bh=" tag, so these are omitted.  The
   signature, once generated, is then added as the value of the "b="
   tag.

   The Original Signer SHOULD use the same selector (and, hence, signing
   key) for DKIM-Delegate fields as it uses for Primary signatures so
   that Domain Name Service caching can be used.

3.5.  Verification

   A Receiver verifies the DKIM-Delegate field by applying the general
   algorithm described in Section 6.1 of [RFC6376] with the following
   caveats:

   o  This specification has a subset of the tags found in a DKIM-
      Signature.  Most notably, DKIM-Delegate has no "v=", "bh=", "c=",
      or "h=" tag.

   A DKIM-Delegate field that verifies contains an explicit list of
   domains authorized to sign content for the Author domain.  The



Kucherawy & Crocker     Expires October 12, 2015                [Page 6]


Internet-Draft                DKIM-Delegate                   April 2015


   Receiver then simply ensures that there is a valid DKIM-Signature
   from one of the delegated domains before concluding that the Author
   domain approved the content.

4.  Expiration

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

   If abuse is detected, the owner of the Author domain can remove the
   key from publication in the DNS as a way of revoking that key and
   thus invalidating any unverified DKIM-Delegate fields.

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.

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 (typically
   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 protocol.

   The "t=" tag might be used to name Mediators that do not appear in
   the To or Cc fields of a message, which means they would normally
   appear in the message envelope only.  Thus, use of that tag records
   envelope details in the message, which could be information intended
   to be kept private.

   As described in Section 3.2, this mechanism signature presents a
   time-limited but nevertheless present opportunity for someone at the



Kucherawy & Crocker     Expires October 12, 2015                [Page 7]


Internet-Draft                DKIM-Delegate                   April 2015


   Mediator's domain to generate content apparently authorized by the
   Author domain.

   Given the exposures described above, message originators would do
   well to consider limiting use of this protocol to those messages that
   will transit trusted Mediators only.  Determining which Mediators are
   worthy of such trust is a local policy matter, outside of the scope
   of this document.

7.  IANA Considerations

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

     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.

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

   [RFC5617]                   Allman, E., Fenton, J., Delany, M., and



Kucherawy & Crocker     Expires October 12, 2015                [Page 8]


Internet-Draft                DKIM-Delegate                   April 2015


                               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
                               Mail (DKIM) Authorized Third-Party
                               Signatures", RFC 6541, February 2012.

Appendix A.  Example

   Given the following message header (numbers in braces are line
   numbers):

       {1}  From: somebody@example.com
       {2}  To: mailinglist@ietf.example
       {3}  Subject: What's up with DKIM?
       {4}  Date: Thu, 12 Jun 2014 11:08:10 -0700
       {5}  DKIM-Signature: v=1; s=rashani; d=example.com;
       {6}      h=from:to:subject:date; ...
       {7}  DKIM-Delegate: a=rsa-sha256; d=example.com; s=rashani;
       {8}      x=1402686254; t=ietf.example; b=<base64-data>
       {9}
       {10} [message body omitted]

   The DKIM signature (line 5) is an Author signature that covers the
   entire message body (the "Primary" signature).  If it validates on
   delivery, the remainder of the DKIM material can be ignored.

   There is also a DKIM-Delegate header field (line 7) that identifies
   the delegating party in its "d=" tag.  It states that signing
   authority is delegated by "example.com" to "ietf.example" (the
   Mediator domain).  The integrity of this field is assured by the fact
   that its signature verified.

   On receipt at the Mediator, both signatures will typically validate.
   The Mediator then augments the content as needed and re-sends the
   message for delivery, this time adding its own signature:










Kucherawy & Crocker     Expires October 12, 2015                [Page 9]


Internet-Draft                DKIM-Delegate                   April 2015


       {1}  From: somebody@example.com
       {2}  To: mailinglist@ietf.example
       {3}  Subject: What's up with DKIM?
       {4}  Date: Thu, 12 Jun 2014 11:08:10 -0700
       {5}  DKIM-Signature: v=1; s=rashani; d=example.com;
       {6}      h=from:to:subject:date; ...
       {7}  DKIM-Delegate: a=rsa-sha256; d=example.com; s=rashani;
       {8}      x=1402686254; t=ietf.example; b=<base64-data>
       {9}  List-Id: mailinglist.ietf.example
       {10} DKIM-Signature: v=1; s=evetastic; d=ietf.example;
       {11}     h=from:to:subject:date:dkim-delegate:list-id; ...
       {12}
       {13} [augmented message body omitted]

   Because of the changed content, the Primary signature no longer
   validates.  However, the Mediator signature will presumably validate
   on receipt, since it covers all of the modified content.  In
   addition, the DKIM-Delegate field would be expected to validate as it
   is unlikely to be altered by Mediators.

   The Receiver of this message (a list subscriber, in this case) can
   conclude that the following are true, based on the remaining valid
   signatures:

   1.  "example.com" authorized "ietf.example" to sign mail on its
       behalf;

   2.  "ietf.example" signed the altered content, thus taking some
       responsibility for it;

   3.  This chain of handling satisfies the need for the Author domain
       to have signed the message; the original message may have been
       modified or replaced, but such action was explicitly approved by
       the Author domain.

Appendix B.  To-Do List

   Stuff to be done:

   o  (nothing right now)

   Some suggestions from others:

   o  Perhaps this is better done by one or more new DKIM-Signature tags
      and/or a version change.  (From John Levine)






Kucherawy & Crocker     Expires October 12, 2015               [Page 10]


Internet-Draft                DKIM-Delegate                   April 2015


Appendix C.  Acknowledgments

   The authors wish to acknowledge Steve Atkins, Barry Leiba, Pete
   Resnick, Hector Santos, Stephen Turnbull, Alessandro Vesely, (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 October 12, 2015               [Page 11]