Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Standards Track                           April 8, 2015
Expires: October 10, 2015


                   Mandatory Tags for DKIM Signatures
                    draft-levine-dkim-conditional-01

Abstract

   The DKIM protocol applies a cryptographic signature to an e-mail
   message.  This specification extends DKIM to allow new signature tags
   that validators are required to evaluate.  The first such tag
   specifies a second signature that must be present 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 October 10, 2015.

Copyright Notice

   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.



Levine                  Expires October 10, 2015                [Page 1]

 
Internet-Draft            DKIM Mandatory Fields               April 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Mandatory DKIM header tags  . . . . . . . . . . . . . . . . .   3
     3.1.  Signature version numbers . . . . . . . . . . . . . . . .   3
     3.2.  Processing mandatory tags . . . . . . . . . . . . . . . .   3
     3.3.  Forward signature (@fs) tag . . . . . . . . . . . . . . .   3
   4.  Typical application scenario  . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

.  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 defines the syntax for new tags in a signature
   header field that specify additional conditions that must be
   satisfied for a signature to be valid.  The first such condition
   requires 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.

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

   Syntax descriptions use Augmented BNF (ABNF)[RFC5234].

   The ABNF "ALPHA", "FWS", "tag-list" and "domain-name" are defined as
   in [RFC6376].








Levine                  Expires October 10, 2015                [Page 2]

 
Internet-Draft            DKIM Mandatory Fields               April 2015


.  Mandatory DKIM header tags

   The current DKIM specification defines a set of header tags, some of
   which are required to appear in every signature and some of which are
   optional.  It also allows a signer to include private tags so long as
   they don't conflict with the registered ones.  Since verifiers ignore
   tags that they don't understand, new tags can only provide new
   information about the message, or enable new verification schemes for
   signatures that would otherwise be considered invalid.

   A Mandatory Tag is a new kind of tag prefixed with an at-sign.  Its
   syntax is otherwise identical to an ordinary tag.

        ABNF:

        tag-spec  =/  [FWS] "@" tag-name [FWS] "=" [FWS] tag-value [FWS]

3.1.  Signature version numbers

   Any DKIM signature with a mandatory tag MUST have version "2" in the
   signature's version tag.

   All valid DKIM version 1 signatures are also valid version 2
   signatures, with "v=1" replaced by "v=2" in the DKIM-Signature
   header.  Signatures without mandatory tags SHOULD continue to use
   version "1" for backward compatibility.

3.2.  Processing mandatory tags

   When a verifier encounters a mandatory tag in a signature, it MUST
   process the tag according to the tag's definition.  If the verifier
   is unable to process the tag the verifier MUST return PERMFAIL for
   that signature.  If there are multiple signatures on a message, the
   verifier continues to verify other signatures as usual.  It is valid
   to have a mixture of version "1" and version "2" signatures on a
   single message.

3.3.  Forward signature (@fs) tag

   The "@fs" mandatory tag means that the signature is only valid if an
   additional signature is present in the message.  The value of the @fs
   tag is the domain of the d= tag of the additional signature.  As a
   special case, the value "T" means that the additional signature can
   be from any of the domains of mailboxes in the message's To header.
   The condition is satisfied if the message includes at least one valid
   DKIM signature header field with responsible domain (the d= tag)
   being one specified by the @fs= tag.




Levine                  Expires October 10, 2015                [Page 3]

 
Internet-Draft            DKIM Mandatory Fields               April 2015


.  Typical application scenario

   A sender that expects a message to be forwarded might put both a
   conventional DKIM signature and a signature with a @fs tag 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
   signature with the @fs tag that matches the other signature, and use
   either or both to assess the message.  If a message arrives with
   signature containing a @fs but no forwarding signature, the recipient
   would ignore that signature.  That signature would typically be a
   "weak" signature covers the From, To, Date, and Message-ID headers
   but 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.

.  IANA Considerations

   IANA is requested to add this entry to the "DKIM-Signature Tag
   Specifications" registry.

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

           Table 1: DKIM-Signature Tag Specifications additions

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

.  Normative References

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





Levine                  Expires October 10, 2015                [Page 4]

 
Internet-Draft            DKIM Mandatory Fields               April 2015


   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [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 October 10, 2015                [Page 5]