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

Versions: 00 01 02 03

Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Standards Track                           June 16, 2014
Expires: December 18, 2014


                      DKIM Conditional Signatures
                    draft-levine-dkim-conditional-00

Abstract

   The DKIM protocol applies a cryptographic signature to an e-mail
   message.  This specification extends DKIM to allow the specification
   of external conditions that must be satisfied for a signature to be
   valid.

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 18, 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.




Levine                  Expires December 18, 2014               [Page 1]


Internet-Draft              DKIM Conditional                   June 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  New DKIM header tags  . . . . . . . . . . . . . . . . . . . .   2
   4.  Condition strings . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Forward signature (fs)  . . . . . . . . . . . . . . . . .   3
   5.  DKIM signature version number . . . . . . . . . . . . . . . .   3
   6.  Typical application scenario  . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   DKIM [RFC6376] defines a cryptographic header field consisting of a
   series of tags and values.  The values include signed hashes of some
   of the header fields and part or all of the body of a message.  The
   signature contains a domain name that is responsible for the
   signature.  The signature is valid if the hashes in the signature
   match the hashes of the header fields and body, the signature is
   valid under a public key retrieved from that responsible domain's
   DNS, and it is before the expiration time in the signature header
   field.

   This specification adds new tags that enable a signature header field
   to specify additional conditions that must be specified for a
   signature to be valid.  A typical condition would be to require the
   presence of an additional signature from a specified different
   domain.  It also defines a new version 2 of the DKIM protocol to
   support the new semantics of conditional signatures.

2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The ABNF terms "ALPHA", "FWS", and "domain-name" are used as in
   [RFC6376].

3.  New DKIM header tags

   cs=  A list of condition strings, each identifying a condition that
      must be satisfied for the signature to be valid.  The initial list
      of condition strings is described below, and placed in the new
      DKIM-Signature Condition String registry.  A verifier MUST check



Levine                  Expires December 18, 2014               [Page 2]


Internet-Draft              DKIM Conditional                   June 2014


      that the condition for each condition string is satisfied.  If any
      of the conditions are not satisfied, or any of the condition
      strings are unknown to the verifier, it MUST report that the
      signature is not valid.

   fs=  A list of forwarding signers.  A forwarding signer is a domain
      name, or the letter "t" meaning any of the domain names in
      addresses in the To header field, or the letter "c" meaning any of
      the domain names in addresses in the Cc header field.  If the tag
      includes "t" or "c", the signature SHOULD include the To or Cc
      header field, respectively.

         ABNF:

         sig-cs-tag       = %x63 %x73 [FWS] "=" [FWS] sig-cs-tag-list

         sig-cs-tag-list = sig-cs-condition 0*( "," sig-cs-condition )

         sig-cs-condition = 1*ALPHA

         sig-fs-tag       = %x63 %x73 [FWS] "=" [FWS] sig-fs-tag-list

         sig-cs-tag-list = sig-fs-signer 0*( "," sig-fs-signer )

         sig-fs-signer = "t" | "c" | domain-name

4.  Condition strings

   This specification defines one condition string and an IANA registry
   to which future condition strings may be added.

4.1.  Forward signature (fs)

   The "fs" condition string means that the signature is only valid if
   an additional signature is present in the message.  There MUST be a
   fs= tag specifying the domains for the additional signature.  The
   condition is satisfied if the message includes at least one valid
   DKIM signature header field with responsible domain (the d= tag)
   being one from the list in the fs= tag.

5.  DKIM signature version number

   Although this specification does not change the syntax of a DKIM
   signature other than by adding additional tags, it changes the
   semantics of signature verification.  Specifically, if a signature
   contains a conditional signature tag, verifiers MUST check that the
   conditions in the tag are satisfied.  The existing DKIM version 1
   specification requires verifiers to ignore unrecognized tags, so this



Levine                  Expires December 18, 2014               [Page 3]


Internet-Draft              DKIM Conditional                   June 2014


   tag is incompatible with existing verifiers.  This specification
   defines an additional version of the DKIM header, version 2.  This
   version is backward compatible with version 1 in that all valid DKIM
   version 1 signatures are also valid version 2 signatures, with "v=1"
   replaced by "v=2" in the DKIM-Signature header.

   Any signature that contains a cs= tag MUST be a version 2 signature.
   Any signature that does not contain a cs= tag SHOULD be a version 1
   signature, for maximum backward compatibility.

6.  Typical application scenario

   A sender that expects a message to be forwarded might put both a
   conventional DKIM signature and a conditional signature that refers
   to the domain name of the expected forwarder.  The forwarder uses the
   conventional signature to assess the message, edits the message, and
   then signs the outgoing message with its own signature.  Subsequent
   recipients observe both the forwarder's signature and the conditional
   signature with a fs= tag that matches the other signature, and use
   either or both to assess the message.  If a message arrives with a
   conditional signature but no forwarding signature, the recipient
   would ignore the conditional signature.  The conditional signature
   would typically be a "weak" signature that does not cover the Subject
   header or the message body, so that it would remain valid even if the
   forwarder makes changes typical of forwarders such as mailing lists.

7.  IANA Considerations

   IANA is requested to add these entries to the "DKIM-Signature Tag
   Specifications" registry.

                    +------+-----------------+--------+
                    | TYPE | REFERENCE       | STATUS |
                    +------+-----------------+--------+
                    |  cs  | (this document) | active |
                    |  fs  | (this document) | active |
                    +------+-----------------+--------+

           Table 1: DKIM-Signature Tag Specifications additions

   IANA is requested to create a new "DKIM-Signature Condition String"
   registry, with the following initial contents.









Levine                  Expires December 18, 2014               [Page 4]


Internet-Draft              DKIM Conditional                   June 2014


                    +------+-----------------+--------+
                    | TYPE | REFERENCE       | STATUS |
                    +------+-----------------+--------+
                    |  fs  | (this document) | active |
                    +------+-----------------+--------+

                 Table 2: DKIM-Signature Condition String

8.  Security Considerations

   DKIM was designed to provide assurances that a message with a valid
   signature was received in essentially the same form that it was sent.
   The forwarding signature condition deliberately circumvents that
   design, to create a loophole for messages intended to be forwarded by
   entities that edit the message.  It opens up a variety of obvious
   replay attacks that may or may not be important depending on both the
   selection of target domains for messages to be forwarded, and the
   behavior of forwarders that receive messages with conditional
   signatures.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Author's Address

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg, NY  14886

   Phone: +1 831 480 2300
   Email: standards@taugh.com
   URI:   http://jl.ly












Levine                  Expires December 18, 2014               [Page 5]


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