Network Working Group J. Levine Internet-Draft Taughannock Networks Intended status: Standards Track May 1, 2014 Expires: November 2, 2014 A DKIM Profile to Enable Message Forwarding draft-levine-may-forward-00 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 2, 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 2, 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 . . . . . . . . . . . . . . . . . . . . . 3 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 2, 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=y", 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 they normally delete incoming DKIM signatures. 4. The May Forward Tag The new "mf=y" tag indicates that a DKIM signature is intended to survive 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. 5. IANA Considerations IANA is requested to add an entry to the "DKIM-Signature Tag Specifications" registry. Levine Expires November 2, 2014 [Page 3] Internet-Draft DKIM May Forward May 2014 +------+-----------------+--------+ | 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. 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 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 2, 2014 [Page 4]