Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
RFC 5016

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                          M. Thomas
Request for Comments: 5016                                 Cisco Systems
Category: Informational                                     October 2007

                          Requirements for a
      DomainKeys Identified Mail (DKIM) Signing Practices Protocol

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
   for domains to assert responsibility for the messages they handle.  A
   related mechanism will allow an administrator to publish various
   statements about their DKIM signing practices.  This document defines
   requirements for this mechanism, distinguishing between those that
   must be satisfied (MUST), and those that are highly desirable
   (SHOULD).

Thomas                       Informational                      [Page 1]
RFC 5016                      DKIM-SSP-REQ                  October 2007

Table of Contents

   1. Introduction ....................................................2
   2. Definitions and Requirements Language ...........................3
   3. SSP Problem Scenarios ...........................................4
      3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
      3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
   4. SSP Deployment Considerations ...................................6
      4.1. Deployment Consideration 1: Outsourced Signing .............6
      4.2. Deployment Consideration 2: Subdomain Coverage .............6
      4.3. Deployment Consideration 3: Resent Original Mail ...........7
      4.4. Deployment Consideration 4: Incremental Deployment
           of Signing .................................................7
      4.5. Deployment Consideration 5: Performance and Caching ........8
      4.6. Deployment Consideration 6: Human Legibility of Practices ..8
      4.7. Deployment Consideration 7: Extensibility ..................8
      4.8. Deployment Consideration 8: Security .......................8
   5. Requirements ....................................................9
      5.1. Discovery Requirements .....................................9
      5.2. SSP Transport Requirements ................................10
      5.3. Practice and Expectation Requirements .....................10
      5.4. Extensibility and Forward Compatibility Requirements ......13
   6. Requirements for SSP Security ..................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative References ......................................14

1.  Introduction

   DomainKeys Identified Mail [RFC4871] defines a message level signing
   and verification mechanism for email.  While a DKIM signed message
   speaks for itself, there is ambiguity if a message doesn't have a
   valid first party signature (i.e., on behalf of the [RFC2822].From
   address): is this to be expected or not?  For email, this is an
   especially difficult problem since there is no expectation of a
   priori knowledge of a sending domain's practices.  This ambiguity can
   be used to mount a bid down attack that is inherent with systems like
   email that allow optional authentication: if a receiver doesn't know
   otherwise, it should not assume that the lack of a valid signature is
   exceptional without other information.  Thus, an attacker can take
   advantage of the ambiguity and simply not sign messages.  If a
   protocol could be developed for a domain to publish its DKIM signing
   practices, a message verifier could take that into account when it
   receives an unsigned piece of email.

Thomas                       Informational                      [Page 2]
RFC 5016                      DKIM-SSP-REQ                  October 2007

   This document defines the requirements for a mechanism that permits
   the publication of Sender Signing Practices (SSP).  The document is
   organized into two main sections: first, a Problem and Deployment
   Scenario section that describes the problems that SSP is intended to
   address as well as the deployment issues surrounding the base
   problems, and the second section is the Requirements that arise
   because of those scenarios.

2.  Definitions and Requirements Language

   o  Domain Holder: the entity that controls the contents of the DNS
      subtree starting at the domain, either directly or by delegation
      via NS records it controls.

   o  First Party Address: for DKIM, a first party address is defined to
      be the [RFC2822].From address in the message header; a first party
      address is also known as an Author address.