Internet DRAFT - draft-levine-cdkim
draft-levine-cdkim
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]
