Network Working Group J. Levine Internet-Draft Taughannock Networks Intended status: Standards Track June 19, 2014 Expires: December 21, 2014 CDKIM Signatures draft-levine-cdkim-00 Abstract The DKIM protocol applies a cryptographic signature to an e-mail message. This specification defines a DKIM-like signature that includes 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 21, 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 21, 2014 [Page 1] Internet-Draft CDKIM June 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The CDKIM signature . . . . . . . . . . . . . . . . . . . . . 2 4. CDKIM header tags . . . . . . . . . . . . . . . . . . . . . . 3 5. Condition strings . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Forward signature (fs) . . . . . . . . . . . . . . . . . 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 defines a new signature with 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. 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. The CDKIM signature A CDKIM signature is identical to a DKIM signature as defined in [RFC6376] except that the header field starts with "CDKIM-Signature" rather than "DKIM-Signature", and each signature MUST include a "cs=" tag. Levine Expires December 21, 2014 [Page 2] Internet-Draft CDKIM June 2014 4. CDKIM 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 CDKIM-Signature Condition String registry. A verifier MUST check 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 5. Condition strings This specification defines one condition string and an IANA registry to which future condition strings may be added. 5.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. Levine Expires December 21, 2014 [Page 3] Internet-Draft CDKIM June 2014 6. Typical application scenario A sender that expects a message to be forwarded might put both a conventional DKIM signature and a CDKIM 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 create the "CDKIM-Signature Tag Specifications" registry and populate it with these tags. +------+-----------------+--------+ | TYPE | REFERENCE | STATUS | +------+-----------------+--------+ | cs | (this document) | active | | fs | (this document) | active | +------+-----------------+--------+ Table 1: CDKIM-Signature Tag Specifications IANA is requested to add these entries to the "DKIM-Signature Tag Specifications" registry, in order to prevent future collisions with the cs= and fs= tags. +------+-----------------+----------+ | TYPE | REFERENCE | STATUS | +------+-----------------+----------+ | cs | (this document) | reserved | | fs | (this document) | reserved | +------+-----------------+----------+ Table 2: DKIM-Signature Tag Specifications additions IANA is requested to create a new "CDKIM-Signature Condition String" registry, with the following initial contents. Levine Expires December 21, 2014 [Page 4] Internet-Draft CDKIM June 2014 +------+-----------------+--------+ | TYPE | REFERENCE | STATUS | +------+-----------------+--------+ | fs | (this document) | active | +------+-----------------+--------+ Table 3: CDKIM-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 CDKIM 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 21, 2014 [Page 5]