Internet DRAFT - draft-levine-may-forward
draft-levine-may-forward
Network Working Group J. Levine
Internet-Draft Taughannock Networks
Intended status: Standards Track May 2, 2014
Expires: November 3, 2014
A DKIM Profile to Enable Message Forwarding
draft-levine-may-forward-01
Abstract
Some mail systems have been observed to use authentication schemes
the domain name in the From: header as a security key, in combination
with DKIM, an approach works poorly in connection with forwarders
that edit messages. This document describes a profile of DKIM
intended to improve interoperation of DKIM with such schemes.
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 November 3, 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 November 3, 2014 [Page 1]
Internet-Draft DKIM May-Forward May 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 2
3. A DKIM Profile for May-Forward . . . . . . . . . . . . . . . 3
4. The May-Forward Tag . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
Some mail systems have been observed to use authentication schemes
the domain name in the From: header as a security key, in combination
with DKIM [RFC6376], an approach works poorly in connection with
forwarders that edit messages. If forwarders edit messages in ways
typical of mailing lists, such as adding subject line tags and
messages headers or footers, existing DKIM signatures are no longer
valid, and such authentication schemes fail. This has been observed
to cause rejection of messages that the recipients want to receive
and other undesirable effects.
Some approaches for modifying mail software to work around this issue
are described in [RFC6377], but due do a combination of non-adoption
and changing security models, they are not adequate.
This document describes a restricted DKIM profile, intended to create
DKIM signatures that will survive message modifications, and a DKIM
signature tag intended to identify such signatures for the benefit of
anti-spam and other assessment schemes.
2. Definitions
2.1. Keywords
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].
Levine Expires November 3, 2014 [Page 2]
Internet-Draft DKIM May-Forward May 2014
3. A DKIM Profile for May-Forward
A "may-forward" DKIM signature is an ordinary DKIM signature that
meets the following criteria:
1. The only signed header is From. That is, the signature header
contains "h=from".
2. The responsible SDID is the domain in the address in the From:
header, that is, the signature header contains "d=fromdomain"
where "fromdimain is that domain.
3. The signature SHOULD use relaxed header canonicalization, that
is, the signature header contains "c=relaxed/relaxed" or
"c=relaxed/simple".
4. The message body is unsigned, that is, the signature header
contains "l=0".
5. The signature header contains the new may-forward tag
"mf=targetdomain", described below.
Other fields in the DKIM signature header such as t= and z= are
created as normal. The signer SHOULD also apply conventional DKIM
signature(s) without the may-forward tag.
A forwarder SHOULD preserve may-forward signatures with d= domains
that match the From: domain, even if it normally deletes incoming
DKIM signatures.
4. The May-Forward Tag
The new "mf=targetdomain" tag indicates that a DKIM signature is
intended to survive forwarding. The "targetdomain" is the domain
name that is expected to do the forwarding. While it has no specific
meaning in the context of DKIM signature validation, it is intended
for use by higher level assessment software to aid in their
evaluation of a message. If a message also has a DKIM signature with
a d= domain that matches the targetdomain in an mf tag, (a
"forwarding signature") that indicates that the message has been
forwarded as anticipated.
A sender that expects a message to be forwarded might put both a
conventional DKIM signature and a may-forward signature. 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 may-forward with an mf tag that matches the other
Levine Expires November 3, 2014 [Page 3]
Internet-Draft DKIM May-Forward May 2014
signature, and use either or both to assess the message. If a
message arrives with a may-forward signature but no forwarding
signature, the recipient would ignore the may-forward signature or
assign it lower weight since the message has not been forwarded as
expected.
5. IANA Considerations
IANA is requested to add an entry to the "DKIM-Signature Tag
Specifications" registry.
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| mf | (this document) | active |
+------+-----------------+--------+
Table 1: DKIM-Signature Tag Specifications additions
6. 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.
This profile 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 may-forward signatures.
7. References
7.1. 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.
7.2. Informative References
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, September 2011.
Author's Address
Levine Expires November 3, 2014 [Page 4]
Internet-Draft DKIM May-Forward May 2014
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 November 3, 2014 [Page 5]
