Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
RFC 5016
|
| Document |
Type |
|
RFC - Informational
(October 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5016 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Tim Polk
|
|
Send notices to |
|
(None)
|
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
Show full document text