Including Recipients in DKIM Signatures
draft-kucherawy-dkim-rcpts-01

Document Type Active Internet-Draft (individual)
Last updated 2016-11-15
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       M. Kucherawy
Internet-Draft                                         November 15, 2016
Intended status: Standards Track
Expires: May 19, 2017

                Including Recipients in DKIM Signatures
                     draft-kucherawy-dkim-rcpts-01

Abstract

   The DomainKeys Identified Mail (DKIM) protocol applies a domain-level
   cryptographic signature to an e-mail message.  DKIM only guarantees
   authenticity of the message content and does not consider the message
   envelope.  This allows for replay attacks by recycling a signed
   message with an arbitrary new set of recipients.

   This document presents a protocol extension that can include original
   envelope information in the signature data, so that an altered that
   information renders the signature invalid.

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 May 19, 2017.

Copyright Notice

   Copyright (c) 2016 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

Kucherawy                 Expires May 19, 2017                  [Page 1]
Internet-Draft        DKIM Canonicalized Recipients        November 2016

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  'nr' Tag Definition . . . . . . . . . . . . . . . . . . . . .   3
   4.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Signers . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Verifiers . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Compatibility with Current Infrastructure . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
   10. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  01 . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.2.  00 . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   DKIM [RFC6376] defines a cryptographic signature, placed in a 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 and thus takes some responsibility for
   the presence of the message in the email stream.

   The signature is valid if the hashes in the signature match the
   corresponding hashes of the message at validation time, the signature
   is validated by a public key retrieved from that responsible domain's
   DNS, and it is before the expiration time in the signature header
   field (if set).

   There have been recent incidents of a replay attack, where a message
   of undesirable content (spam, malware, phishing, etc.) is sent by a
   bad actor to itself through an email service, which dutifully signs
   it.  This message now bears the digital signature of the signing
Show full document text