draft-ietf-dkim-ssp-requirements-05.txt   rfc5016.txt 
DKIM Working Group M. Thomas Network Working Group M. Thomas
Internet-Draft Cisco Systems Request for Comments: 5016 Cisco Systems
Intended status: Informational August 11, 2007 Category: Informational October 2007
Expires: February 12, 2008
Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 12, 2008. Requirements for a
DomainKeys Identified Mail (DKIM) Signing Practices Protocol
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). 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 Abstract
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
for domains to assert responsibility for the messages they handle. A for domains to assert responsibility for the messages they handle. A
related mechanism will allow an administrator to publish various related mechanism will allow an administrator to publish various
statements about their DKIM signing practices. This document defines statements about their DKIM signing practices. This document defines
requirements for this mechanism, distinguishing between those that requirements for this mechanism, distinguishing between those that
must be satisified (MUST), and those that are highly desirable must be satisfied (MUST), and those that are highly desirable
(SHOULD). (SHOULD).
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................2
2. Definitions and Requirements Language ...........................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. SSP Problem Scenarios ...........................................4
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
3. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 7 3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? . . . . 7 4. SSP Deployment Considerations ...................................6
3.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 8 4.1. Deployment Consideration 1: Outsourced Signing .............6
4.2. Deployment Consideration 2: Subdomain Coverage .............6
4. SSP Deployment Considerations . . . . . . . . . . . . . . . . 10 4.3. Deployment Consideration 3: Resent Original Mail ...........7
4.1. Deployment Consideration 1: Outsourced Signing . . . . . . 10 4.4. Deployment Consideration 4: Incremental Deployment
4.2. Deployment Consideration 2: Subdomain Coverage . . . . . . 10 of Signing .................................................7
4.3. Deployment Consideration 3: Resent Original Mail . . . . . 10 4.5. Deployment Consideration 5: Performance and Caching ........8
4.4. Deployment Consideration 4: Incremental Deployment of 4.6. Deployment Consideration 6: Human Legibility of Practices ..8
Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Deployment Consideration 7: Extensibility ..................8
4.5. Deployment Consideration 5: Performance and Caching . . . 11 4.8. Deployment Consideration 8: Security .......................8
4.6. Deployment Consideration 6: Human Legibility of 5. Requirements ....................................................9
Practices . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Discovery Requirements .....................................9
4.7. Deployment Consideration 7: Extensibility . . . . . . . . 12 5.2. SSP Transport Requirements ................................10
4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12 5.3. Practice and Expectation Requirements .....................10
5.4. Extensibility and Forward Compatibility Requirements ......13
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Requirements for SSP Security ..................................13
5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13 7. Security Considerations ........................................13
5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14 8. Acknowledgments ................................................13
5.3. Practice and Expectation Requirements . . . . . . . . . . 14 9. References .....................................................14
5.4. Extensibility and Forward Compatibility Requirements . . . 16 9.1. Normative References ......................................14
6. Requirements for SSP Security . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
DomainKeys Identified Mail [RFC4871] defines a message level signing DomainKeys Identified Mail [RFC4871] defines a message level signing
and verification mechanism for email. While a DKIM signed message and verification mechanism for email. While a DKIM signed message
speaks for itself, there is ambiguity if a message doesn't have a speaks for itself, there is ambiguity if a message doesn't have a
valid first party signature (ie, on behalf of the [RFC2822].From 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 address): is this to be expected or not? For email, this is an
especially difficult problem since there is no expectation of a especially difficult problem since there is no expectation of a
priori knowledge of a sending domain's practices. This ambiguity can 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 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 email that allow optional authentication: if a receiver doesn't know
otherwise, it should not assume that the lack of a valid signature is otherwise, it should not assume that the lack of a valid signature is
exceptional without other information. Thus, an attacker can take exceptional without other information. Thus, an attacker can take
advantage of the ambiguity and simply not sign messages. If a advantage of the ambiguity and simply not sign messages. If a
protocol could be developed for a domain to publish its DKIM signing protocol could be developed for a domain to publish its DKIM signing
practices, a message verifier could take that into account when it practices, a message verifier could take that into account when it
receives an unsigned piece of email. receives an unsigned piece of email.
This document defines the requirements for a mechanism that permits This document defines the requirements for a mechanism that permits
the publication of Sender Signing Practices (SSP). The document is the publication of Sender Signing Practices (SSP). The document is
organized into two main sections: a Problem and Deployment Scenario organized into two main sections: first, a Problem and Deployment
section which describes the problems that SSP is intended to address Scenario section that describes the problems that SSP is intended to
as well as the deployment issues surrounding the base problems. The address as well as the deployment issues surrounding the base
second section is the Requirements that arise because of those problems, and the second section is the Requirements that arise
scenarios. because of those scenarios.
2. Definitions 2. Definitions and Requirements Language
o Domain Holder: the entity that controls the contents of the DNS o Domain Holder: the entity that controls the contents of the DNS
subtree starting at the domain, either directly or by delegation subtree starting at the domain, either directly or by delegation
via NS records it controls. via NS records it controls.
o First Party Address: For DKIM, a first party address is defined to 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 be the [RFC2822].From address in the message header; a first party
address is also known as an Author address address is also known as an Author address.
o First Party Signature: a first party signature is a valid o First Party Signature: a first party signature is a valid
signature where the signing identity (the d= tag or the more signature where the signing identity (the d= tag or the more
specific identity i= tag) matches the first party address. specific identity i= tag) matches the first party address.
"Matches" in this context is defined in [RFC4871]. "Matches" in this context is defined in [RFC4871].
o Third Party Signature: a third party signature is a valid o Third Party Signature: a third party signature is a valid
signature that does not qualify as a First Party Signature. Note signature that does not qualify as a first party signature. Note
that a DKIM third party signature is not required to correspond to that a DKIM third party signature is not required to correspond to
a header field address such as the contents of Sender or List-Id, a header field address such as the contents of Sender or List-Id,
etc. etc.
o Practice: a statement according to the [RFC2822].From domain o Practice: a statement according to the [RFC2822].From domain
holder of externally verifiable behavior in the email messages it holder of externally verifiable behavior in the email messages it
sends. sends.
o Expectation: an Expectation combines with a Practice to convey o Expectation: an expectation combines with a practice to convey
what the domain holder considers the likely survivability of the what the domain holder considers the likely survivability of the
Practice for a receiver, in particular receivers that may be more practice for a receiver, in particular receivers that may be more
than one SMTP hop away. than one SMTP hop away.
o DKIM Signing Complete: a Practice where the domain holder asserts o DKIM Signing Complete: a practice where the domain holder asserts
that all legitimate mail will be sent with a valid First Party that all legitimate mail will be sent with a valid first party
Signature. signature.
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 RFC 2119 [RFC2119].
3. SSP Problem Scenarios 3. SSP Problem Scenarios
The email world is a diverse place with many deployment The email world is a diverse place with many deployment
considerations. This section outlines expected usage scenarios where considerations. This section outlines expected usage scenarios where
DKIM signing/verifying will take place, and how a new protocol might DKIM signing/verifying will take place, and how a new protocol might
help to clarify the relevance of DKIM-signed mail. help to clarify the relevance of DKIM-signed mail.
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? 3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
After auditing their outgoing mail and deploying DKIM signing for all After auditing their outgoing mail and deploying DKIM signing for all
of their legitimate outgoing mail, a domain could be said to be DKIM of their legitimate outgoing mail, a domain could be said to be DKIM
signing complete. That is, the domain has to the best of its ability signing complete. That is, the domain has, to the best of its
ensured that all legitimate mail purporting to have come from that ability, ensured that all legitimate mail purporting to have come
domain contains a valid DKIM signature. from that domain contains a valid DKIM signature.
A receiver in the general case doesn't know what the practices are A receiver in the general case doesn't know what the practices are
for a given domain. Thus, the receiver is at a disadvantage in not for a given domain. Thus, the receiver is at a disadvantage in not
knowing whether it should expect all mail to be signed from a given knowing whether or not it should expect all mail to be signed from a
domain or not. This knowledge gap leads to a trivially exploitable given domain. This knowledge gap leads to a trivially exploitable
bid-down attack where the attacker merely sends unsigned mail; since bid-down attack where the attacker merely sends unsigned mail; since
the receiver doesn't know the practices of the signing domain, it the receiver doesn't know the practices of the signing domain, it
cannot treat the message any more harshly for lack of a valid cannot treat the message any more harshly for lack of a valid
signature. signature.
An information service which allows a receiver to query for the An information service that allows a receiver to query for the
practices and expectations of the first party domain when no valid practices and expectations of the first party domain when no valid
first party signature is found could be useful in closing this gap. first party signature is found could be useful in closing this gap.
A receiver could use this information to treat such questionable mail A receiver could use this information to treat such questionable mail
with varying degrees of prejudice. with varying degrees of prejudice.
Note that for the foreseeable future, unrestricted use patterns of Note that, for the foreseeable future, unrestricted use patterns of
mail (eg where users may be members of mailing lists, etc) will mail (e.g., where users may be members of mailing lists, etc.) will
likely suffer occasional non-malicious signature failure in transit. likely suffer occasional, non-malicious signature failure in transit.
While probably not a large percentage of total traffic, the kind of While probably not a large percentage of total traffic, this kind of
breakage may be a significant concern for those usage patterns. This breakage may be a significant concern for those usage patterns. This
scenario defines where the sender cannot set any expectation as to scenario defines where the sender cannot set any expectation as to
whether an individual message will arrive intact. whether an individual message will arrive intact.
Even without that expectation, a receiver may be able to take Even without that expectation, a receiver may be able to take
advantage of the knowledge that the domain's practice is to sign all advantage of the knowledge that the domain's practice is to sign all
mail and bias its filters against unsigned or damaged in transit mail and bias its filters against unsigned or damaged in transit
mail. This information should not be expected to be used in a binary mail. This information should not be expected to be used in a binary
yes/no fashion, but instead as a data point among others in a yes/no fashion, but instead as a data point among others in a
filtering system. filtering system.
The following exchange illustrates problem scenario 1. The following exchange illustrates problem scenario 1.
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
with a missing or broken DKIM first party signature from Alice with a missing or broken DKIM first party signature from Alice.
2. Domain Bob would like to know whether that is an expected state 2. Domain Bob would like to know whether that is an expected state
of affairs. of affairs.
3. Domain Alice provides information that it signs all outgoing 3. Domain Alice provides information that it signs all outgoing
mail, but places no expectation on whether it will arrive with an mail, but places no expectation on whether it will arrive with an
intact first party signature. intact first party signature.
4. Domain Bob could use this information to bias its filters to 4. Domain Bob could use this information to bias its filters to
examines the message with some suspicion. examine the message with some suspicion.
3.2. Problem Scenario 2: Illegitimate Domain Name Use 3.2. Problem Scenario 2: Illegitimate Domain Name Use
A class of mail typified by transactional mail from high value A class of mail typified by transactional mail from high-value
domains is currently the target of phishing attacks. In particular, domains is currently the target of phishing attacks. In particular,
many phishing scams forge the [RFC2822].From address in addition to many phishing scams forge the [RFC2822].From address in addition to
spoofing much of the content to trick unsuspecting users into spoofing much of the content to trick unsuspecting users into
revealing sensitive information. Domain holders sending this mail revealing sensitive information. Domain holders sending this mail
would like the ability to give an enhanced guarantee that mail sent would like the ability to give an enhanced guarantee that mail sent
with their domain name should always arrive with the proof that the with their domain name should always arrive with the proof that the
domain holder consented to its transmission. That is, the message domain holder consented to its transmission. That is, the message
should contain a valid first party signature as defined above. should contain a valid first party signature as defined above.
From a receiver's standpoint, knowing that a domain not only signs From a receiver's standpoint, knowing that a domain not only signs
all of its mail, but places a very high value on the receipt of a all of its mail, but places a very high value on the receipt of a
valid first party signature from that domain is helpful. Hence a valid first party signature from that domain is helpful. Hence, a
receiver can know that the domain not only signs all of its mail, but receiver knows that the sending domain signs all its mail, and that
also feels it essential that legitimate mail must have its first the sending domain considers mail from this domain particularly
party signatures survive transit. A receiver with the knowledge of sensitive in some sense, and is asking the receiver to be more
the sender's expectations in hand might choose to process messages suspicious than it otherwise might be of a broken or missing first-
not conforming to the published practices in a special manner. Note party signature. A receiver with the knowledge of the sender's
that the ability to state an enhanced guarantee of a valid signature expectations in hand might choose to process messages not conforming
means that senders should expect mail that traverses modifying to the published practices in a special manner. Note that the
intermediaries (eg, mailing lists, etc) will be likely be quarantined ability to state an enhanced guarantee of a valid signature means
or deleted, thus this scenario is more narrow than problem scenario that senders should expect mail that traverses modifying
intermediaries (e.g., mailing lists, etc.) will likely be quarantined
or deleted; thus, this scenario is more narrow than problem scenario
1. 1.
[Informative Note: a receiving filter may choose to treat scenario Informative Note: a receiving filter may choose to treat scenario
2 much more harshly than scenario 1; where scenario 1 looks odd, 2 much more harshly than scenario 1; where scenario 1 looks odd,
scenario 2 looks like something is very wrong] scenario 2 looks like something is very wrong.
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
with a missing or broken first party DKIM signature from domain with a missing or broken first party DKIM signature from domain
Alice Alice.
2. Domain Bob would like to know whether that is an expected state 2. Domain Bob would like to know whether that is an expected state
of affairs. of affairs.
3. Domain Alice provides information that it signs all outgoing 3. Domain Alice provides information that it signs all outgoing
mail, and furthermore places an expectation that it should arrive mail, and furthermore places an expectation that it should arrive
with an intact first party signature, and that the receiver with an intact first party signature, and that the receiver
should be much more wary if it does not. should be much more wary if it does not.
4. Domain Bob could use this information to bias its filters such 4. Domain Bob could use this information to bias its filters such
that it examines the message with great suspicion. that it examines the message with great suspicion.
skipping to change at page 10, line 17 skipping to change at page 6, line 32
Given the problems enumerated above for which we'd like SSP to Given the problems enumerated above for which we'd like SSP to
provide information to recipients, there are a number of scenarios provide information to recipients, there are a number of scenarios
that are not related to the problems that are to be solved, per se, that are not related to the problems that are to be solved, per se,
but the actual mechanics of implementing/deploying the information but the actual mechanics of implementing/deploying the information
service that SSP would provide. service that SSP would provide.
4.1. Deployment Consideration 1: Outsourced Signing 4.1. Deployment Consideration 1: Outsourced Signing
Many domains do not run their own mail infrastructure, or may Many domains do not run their own mail infrastructure, or may
outsource parts of it to third parties. It is desirable for a domain outsource parts of it to third parties. It is desirable for a domain
holder to have the ability delegate to other entities the ability to holder to have the ability to delegate to other entities the ability
sign for the domain holder. One obvious use scenario is a domain to sign for the domain holder. One obvious use scenario is a domain
holder from a small domain that needs to have the ability for their holder from a small domain that needs to have the ability for their
outgoing ISP to sign all of their mail on behalf of the domain outgoing ISP to sign all of their mail on behalf of the domain
holder. Other use scenarios include outsourced bulk mail for holder. Other use scenarios include outsourced bulk mail for
marketing campaigns, as well as outsourcing various business marketing campaigns, as well as outsourcing various business
functions such as insurance benefits, etc. functions, such as insurance benefits, etc.
4.2. Deployment Consideration 2: Subdomain Coverage 4.2. Deployment Consideration 2: Subdomain Coverage
A SSP client will perform lookups on incoming mail streams to provide An SSP client will perform lookups on incoming mail streams to
the information as proposed in the problem scenarios. The domain provide the information as proposed in the problem scenarios. The
part of the first address of the [RFC2822].From will form the basis domain part of the first address of the [RFC2822].From will form the
to fetch the published information. A trivial attack to circumvent basis to fetch the published information. A trivial attack to
finding the published information can be mounted by simply using a circumvent finding the published information can be mounted by simply
subdomain of the parent domain which doesn't have published using a subdomain of the parent domain that doesn't have published
information. This attack is called the subdomain attack: that is, a information. This attack is called the subdomain attack: that is, a
domain wants to not only publish a policy for a given DNS label it domain wants to not only publish a policy for a given DNS label it
controls, but it would also like to protect all subdomains of that controls, but it would also like to protect all subdomains of that
label as well. If this characteristic is not met, an attacker would label as well. If this characteristic is not met, an attacker would
need only create a possibly fictitious subdomain that was not covered need only create a possibly fictitious subdomain that was not covered
by SSP's information service. Thus, it would be advantageous for SSP by the SSP's information service. Thus, it would be advantageous for
to not only cover a given domain, but all subdomains of that domain SSP to not only cover a given domain, but all subdomains of that
as well. domain as well.
4.3. Deployment Consideration 3: Resent Original Mail 4.3. Deployment Consideration 3: Resent Original Mail
Resent mail is a common occurrence in many scenarios in the email Resent mail is a common occurrence in many scenarios in the email
world of today. For example, domain Alice sends a DKIM signed world of today. For example, domain Alice sends a DKIM-signed
message with a published practice of signing all messages to domain message with a published practice of signing all messages to domain
Bob's mailing list. Bob, being a good net citizen, wants to be able Bob's mailing list. Bob, being a good net citizen, wants to be able
to take his part of the responsibility of the message in question, so to take his part of the responsibility of the message in question, so
he DKIM signs the message, perhaps corresponding to the Sender he DKIM signs the message, perhaps corresponding to the Sender
address. address.
Note that this scenario is completely orthogonal to whether Alice's Note that this scenario is completely orthogonal to whether Alice's
signature survived Bob's mailing list: Bob merely wants to assert his signature survived Bob's mailing list: Bob merely wants to assert his
part in the chain of accountability for the benefit of the ultimate part in the chain of accountability for the benefit of the ultimate
receivers. It would be useful for this practice to be encouraged as receivers. It would be useful for this practice to be encouraged as
it gives a more accurate view of who handled the message. It also it gives a more accurate view of who handled the message. It also
has the side benefit that remailers that are not friendly to DKIM has the side benefit that remailers that break DKIM first party
first party signatures (ie, break them) can be potentially assessed signatures can be potentially assessed by the receiver based on the
by the receiver based on the receiver's opinion of the signing receiver's opinion of the signing domains that actually survived.
domains that actually survived.
4.4. Deployment Consideration 4: Incremental Deployment of Signing 4.4. Deployment Consideration 4: Incremental Deployment of Signing
As a practical matter, it may be difficult for a domain to roll out As a practical matter, it may be difficult for a domain to roll out
DKIM signing such that they can publish the DKIM Signing Complete DKIM signing such that they can publish the DKIM Signing Complete
practice given the complexities of the user population, outsourced practice given the complexities of the user population, the
vendors sending on its behalf, etc. This leaves open an exploit that outsourced vendors sending on its behalf, etc. This leaves open an
high-value mail such as in Problem Scenario 2 must be classified to exploit that high-value mail, such as in Problem Scenario 2, must be
the least common denominator of the published practices. It would be classified to the least common denominator of the published
desirable to allow a domain holder to publish a list of exceptions practices. It would be desirable to allow a domain holder to publish
which would have a more restrictive practices statement. NB: this a list of exceptions that would have a more restrictive practices
consideration has been deemed met by the mechanisms provided by the statement. NB: this consideration has been deemed met by the
base DKIM signing mechanism; it is merely documented here as having mechanisms provided by the base DKIM signing mechanism; it is merely
been an issue. documented here as having been an issue.
For example, bigbank.example.com might be ready to say that For example, bigbank.example.com might be ready to say that
statements@bigbank.example.com is always signed, but the rest of the statements@bigbank.example.com is always signed, but the rest of the
domain, say, is not. Another situation is that the practices of some domain, say, is not. Another situation is that the practices of some
address local parts in a given domain are not the same as practices address local parts in a given domain are not the same as practices
of other local parts. Using the same example of of other local parts. Using the same example of
statements@bigbank.example.com being a transactional kind of email statements@bigbank.example.com being a transactional kind of email
which would like to publish very strong practices, mixed in with the that would like to publish very strong practices, mixed in with the
rest of the user population local parts which may go through mailing rest of the user population local parts, which may go through mailing
lists, etc, for which a less strong statement is appropriate. lists, etc., for which a less strong statement is appropriate.
It should be said that DKIM, through the use of subdomains, can It should be said that DKIM, through the use of subdomains, can
already support this kind of differentiation. That is, in order to already support this kind of differentiation. That is, in order to
publish a strong practice, one only has to segregate those cases into publish a strong practice, one only has to segregate those cases into
different subdomains. For example: accounts.bigbank.example.com different subdomains. For example: accounts.bigbank.example.com
would publish constrained practices while would publish constrained practices, while
corporateusers.bigbank.example.com might publish more permissive corporateusers.bigbank.example.com might publish more permissive
practices. practices.
4.5. Deployment Consideration 5: Performance and Caching 4.5. Deployment Consideration 5: Performance and Caching
Email service provides an any-any mesh of potential connections: all Email service provides an any-any mesh of potential connections: all
that is required is the publication of an MX record and a SMTP that is required is the publication of an MX record and an SMTP
listener to receive mail. Thus the use of SSP is likely to fall into listener to receive mail. Thus, the use of SSP is likely to fall
two main scenarios, the first of which are large, well known domains into two main scenarios, the first of which are large, well-known
who are in constant contact with one another. In this case caching domains that are in constant contact with one another. In this case,
of records is essential for performance, including the caching of the caching of records is essential for performance, including the
non-existence of records (ie, negative caching). caching of the non-existence of records (i.e., negative caching).
The second main scenario is when a domain exchanges mail with a much The second main scenario is when a domain exchanges mail with a much
smaller volume domain. This scenario can be both perfectly normal as smaller volume domain. This scenario can be both perfectly normal as
with the case of vanity domains, and unfortunately a vector for those with the case of vanity domains, and unfortunately, a vector for
sending mail for anti-social reasons. In this case we'd like the those sending mail for anti-social reasons. In this case, we'd like
message exchange burden to SSP querier to be low, since many of the the message exchange burden to SSP querier to be low, since many of
lookups will not provide a useful answer. Likewise, it would be the lookups will not provide a useful answer. Likewise, it would be
advantageous to have upstream caching here as well so that, say, a advantageous to have upstream caching here as well so that, say, a
mailing list exploder on a small domain does not result in an mailing list exploder on a small domain does not result in an
explosion of queries back at the root and authoritative server for explosion of queries back at the root and authoritative server for
the small domain. the small domain.
4.6. Deployment Consideration 6: Human Legibility of Practices 4.6. Deployment Consideration 6: Human Legibility of Practices
While SSP records are likely to be primarily consumed by an While SSP records are likely to be primarily consumed by an
automaton, for the foreseeable future they are also likely to be automaton, for the foreseeable future they are also likely to be
inspected by hand. It would be nice to have the practices stated in inspected by hand. It would be nice to have the practices stated in
a fashion which is also intuitive to the human inspectors. a fashion that is also intuitive to the human inspectors.
4.7. Deployment Consideration 7: Extensibility 4.7. Deployment Consideration 7: Extensibility
While this document pertains only to requirements surrounding DKIM While this document pertains only to requirements surrounding DKIM
signing practices, it would be beneficial for the protocol to be able signing practices, it would be beneficial for the protocol to be able
to extend to other protocols. to extend to other protocols.
4.8. Deployment Consideration 8: Security 4.8. Deployment Consideration 8: Security
SSP must be able to withstand life in a hostile open internet SSP must be able to withstand life in a hostile, open-Internet
environment. These include DoS attacks, and especially DoS attacks environment. These include DoS attacks, and especially DoS attacks
that leverage themselves through amplification inherent in the that leverage themselves through amplification inherent in the
protocol. In addition, while a useful protocol may be built without protocol. In addition, while a useful protocol may be built without
strong source authentication provided by the information service, a strong source authentication provided by the information service, a
path to strong source authentication should be provided by the path to strong source authentication should be provided by the
protocol, or underlying protocols. protocol, or underlying protocols.
5. Requirements 5. Requirements
This section defines the requirements for SSP. As with most This section defines the requirements for SSP. As with most
skipping to change at page 13, line 20 skipping to change at page 9, line 23
be noted that SSP must fulfill all of the requirements. be noted that SSP must fulfill all of the requirements.
5.1. Discovery Requirements 5.1. Discovery Requirements
Receivers need a means of obtaining information about a sender's DKIM Receivers need a means of obtaining information about a sender's DKIM
practices. This requires a means of discovering where the practices. This requires a means of discovering where the
information is and what it contains. information is and what it contains.
1. The author is the first-party sender of a message, as specified 1. The author is the first-party sender of a message, as specified
in the [RFC2822].From field. SSP's information is associated in the [RFC2822].From field. SSP's information is associated
with the author's domain name and is published subordinate to with the author's domain name, and is published subordinate to
that domain name. that domain name.
2. In order to limit the cost of its use, any query service 2. In order to limit the cost of its use, any query service
supplying SSP's information MUST provide a definitive responsive supplying SSP's information MUST provide a definitive response
within a small, deterministic number of message exchanges under within a small, deterministic number of message exchanges under
normal operational conditions. normal operational conditions.
[Informative Note: this, for all intents and purposes is a Informative Note: this, for all intents and purposes is a
prohibition on anything that might produce loops or result in prohibition on anything that might produce loops or result in
extended delays and overhead; also though "deterministic" extended delays and overhead; also though "deterministic"
doesn't specify how many exchanges, the expectation is "few".] doesn't specify how many exchanges, the expectation is "few".
[Refs: Deployment Considerations 2, 5] Refs: Deployment Considerations, Sections 4.2 and 4.5.
3. SSP's publishing mechanism MUST be defined such that it does not 3. SSP's publishing mechanism MUST be defined such that it does not
lead to multiple resource records of the same type for different lead to multiple resource records of the same type for different
protocols residing at the same location. protocols residing at the same location.
[Informative note: An example is multiple resource record of Informative note: an example is multiple resource record of the
the same type within a common DNS leaf. Hence, uniquely same type within a common DNS leaf. Hence, uniquely defined
defined leaf names or uniquely defined resource record types leaf names or uniquely defined resource record types will
will ensure unambiguous reference.] ensure unambiguous referencing.
[Refs: Deployment Consideration 2] Refs: Deployment Consideration, Section 4.2.
4. SSP retrieval SHOULD provide coverage for not only a given domain 4. SSP retrieval SHOULD provide coverage for not only a given domain
but all of its subdomains as well. It is recognized that there but all of its subdomains as well. It is recognized that there
is some reasonable doubt about the feasibility of a widely is some reasonable doubt about the feasibility of a widely
accepted solution to this requirement. If the working group does accepted solution to this requirement. If the working group does
not achieve rough consensus on a solution, it MUST document the not achieve rough consensus on a solution, it MUST document the
relevant security considerations in the protocol specification. relevant security considerations in the protocol specification.
[Refs: Deployment Considerations 2, 5] Refs: Deployment Considerations, Sections 4.2 and 4.5.
5.2. SSP Transport Requirements 5.2. SSP Transport Requirements
The publication and query mechanism will operate as an an internet- The publication and query mechanism will operate as an internet-based
based message exchange. There are multiple requirements for this message exchange. There are multiple requirements for this lower-
lower layer service: layer service:
1. The exchange SHOULD have existing widespread deployment of the 1. The exchange SHOULD have existing widespread deployment of the
transport layer, especially if riding on top of a true transport transport layer, especially if riding on top of a true transport
layer (eg, TCP, UDP). layer (e.g., TCP, UDP).
[Refs: Deployment Considerations 5, 7] Refs: Deployment Considerations, Sections 4.5 and 4.7.
2. The query/response in terms of latency time and the number of 2. The query/response in terms of latency time and the number of
messages involved MUST be low (less than three message exchanges messages involved MUST be low (less than three message exchanges
not counting retransmissions or other exceptional conditions). not counting retransmissions or other exceptional conditions).
[Refs: Deployment Consideration 5] Refs: Deployment Consideration, Section 4.5.
3. If the infrastructure doesn't provide caching (a la DNS), the 3. If the infrastructure doesn't provide caching (a la DNS), the
records retrieved MUST provide initiators the ability maintain records retrieved MUST provide initiators the ability to maintain
their own cache. Existing caching infrastructure is, however, their own cache. The existing caching infrastructure is,
highly desirable. however, highly desirable.
[Refs: Deployment Consideration 5] Refs: Deployment Consideration, Section 4.5.
4. Multiple geographically and topologically diverse servers MUST be 4. Multiple geographically and topologically diverse servers MUST be
supported for high availability supported for high availability.
[Refs: Deployment Considerations 5, 7] Refs: Deployment Considerations, Sections 4.5 and 4.7.
5.3. Practice and Expectation Requirements 5.3. Practice and Expectation Requirements
As stated in the definitions a Practice is a statement according to As stated in the definitions section, a practice is a statement
the [RFC2822].From domain holder of externally verifiable behavior in according to the [RFC2822].From domain holder of externally
the email messages it sends. As an example, a Practice might be verifiable behavior in the email messages it sends. As an example, a
defined that all email messages will contain a DKIM signature practice might be defined such that all email messages will contain a
corresponding to the [RFC2822].From address. Since there is a DKIM signature corresponding to the [RFC2822].From address. Since
possibility of alteration between what a sender sends and a receiver there is a possibility of alteration between what a sender sends and
examines, an Expectation combines with a Practice to convey what the a receiver examines, an expectation combines with a practice to
[RFC2822].From domain considers the likely outcome of the convey what the [RFC2822].From domain considers the likely outcome of
survivability of the Practice at a receiver. For example, a Practice the survivability of the practice at a receiver. For example, a
that a valid DKIM for the [RFC2822].From address is present when it practice that a valid DKIM for the [RFC2822].From address is present
is sent from the domain, and an Expectation that it will remain when it is sent from the domain, and an expectation that it will
present and valid for all receivers whether topologically adjacent or remain present and valid for all receivers whether topologically
not. adjacent or not.
1. SSP MUST be able to make Practices and Expectation assertions 1. SSP MUST be able to make practices and expectation assertions
about the domain part of a [RFC2822].From address in the context about the domain part of a [RFC2822].From address in the context
of DKIM. SSP will not make assertions about other addresses for of DKIM. SSP will not make assertions about other addresses for
DKIM at this time. DKIM at this time.
[Refs: Problem Scenarios 1,2] Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
2. SSP MUST provide a concise linkage between the [RFC2822].From 2. SSP MUST provide a concise linkage between the [RFC2822].From and
and the identity in the DKIM i= tag, or its default if it is the identity in the DKIM i= tag, or its default if it is missing
missing in the signature. That is, SSP MUST precisely define in the signature. That is, SSP MUST precisely define the
the semantics of what qualifies as a First Party Signature. semantics of what qualifies as a first party signature.
[Refs: Problem Scenarios 1,2] Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
3. SSP MUST be able to publish a Practice that the domain's signing 3. SSP MUST be able to publish a practice that the domain's signing
behavior is "DKIM Signing Complete". That is, all messages were behavior is "DKIM Signing Complete". That is, all messages were
transmitted with a valid first party signature. transmitted with a valid first party signature.
[Refs: Problem Scenario 1] Refs: Problem Scenario 1, Section 3.1.
4. SSP MUST be able to publish an Expectation that a verifiable 4. SSP MUST be able to publish an expectation that a verifiable
first party DKIM Signature should be expected on receipt of a first party DKIM signature should be expected on receipt of a
message. message.
[Refs: Problem Scenario 2] Refs: Problem Scenario 2, Section 3.2.
5. Practices and Expectations MUST be presented in SSP syntax using 5. Practices and expectations MUST be presented in SSP syntax using
as intuitive a descriptor as possible. For example, p=? would as intuitive a descriptor as possible. For example, p=? would be
be better represented as p=unknown. better represented as p=unknown.
[Refs: Deployment Consideration 6] Refs: Deployment Consideration, Section 4.6.
6. Because DKIM uses DNS to store selectors, there is always the 6. Because DKIM uses DNS to store selectors, there is always the
ability for a domain holder to delegate all or parts of the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to an affiliated party of the domain _domainkey subdomain to an affiliated party of the domain
holder's choosing. That is, the domain holder may set an NS holder's choosing. That is, the domain holder may set an NS
record for _domainkey.example.com to delegate to an email record for _domainkey.example.com to delegate to an email
provider who manages the entire namespace. There is also the provider who manages the entire namespace. There is also the
ability for the domain holder to partition its namespace into ability for the domain holder to partition its namespace into
subdomains to further constrain third parties. For example, a subdomains to further constrain third parties. For example, a
domain holder could delegate only domain holder could delegate only _domainkey.benefits.example.com
_domainkey.benefits.example.com to a third party to constrain to a third party to constrain the third party to only be able to
the third party to only be able to produce valid signatures in produce valid signatures in the benefits.example.com subdomain.
the benefits.example.com subdomain. Last, a domain holder can Last, a domain holder can even use CNAME's to delegate individual
even use CNAME's to delegate individual leaf nodes. Given the leaf nodes. Given the above considerations, SSP need not invent
above considerations, SSP need not invent a different means of a different means of allowing affiliated parties to sign on a
allowing affiliated parties to sign on a domain's behalf at this domain's behalf at this time.
time.
[Refs: Deployment Consideration 4] Refs: Deployment Consideration, Section 4.4.
7. Practices and Expectations MUST be presented as an information 7. Practices and expectations MUST be presented as an information
service from the signing domain to be consumed as an added service from the signing domain to be consumed as an added factor
factor to the receiver's local policy. In particular, a to the receiver's local policy. In particular, a practice or
Practice or Expectation MUST NOT mandate any disposition stance expectation MUST NOT mandate any disposition stance on the
on the receiver. receiver.
[Refs: Problem Scenarios 1, 2] Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
8. There is no requirement that SSP publish a Practices of any/all 8. There is no requirement that SSP publish practices of any/all
third parties that MUST NOT sign on the domain holder's behalf. third parties that MUST NOT sign on the domain holder's behalf.
This should be considered out of scope. This should be considered out of scope.
[INFORMATIVE NOTE: this is essentially saying that the INFORMATIVE NOTE: this is essentially saying that the protocol
protocol doesn't have to concern itself with being a doesn't have to concern itself with being a blacklist
blacklist repository.] repository.
[Refs: Problem Scenarios 1,2] Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
9. SSP MUST NOT be required to be invoked if a valid first party 9. SSP MUST NOT be required to be invoked if a valid first party
signature is found. signature is found.
[Refs: Deployment Consideration 2] Refs: Deployment Consideration, Section 4.2.
10. SSP MUST NOT provide a mechanism which impugns the existence of 10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of requirement is that the protocol MUST NOT link practices of first
first party signers with the practices of third party signers. party signers with the practices of third party signers.
[INFORMATIVE NOTE: the main thrust of this requirement is INFORMATIVE NOTE: the main thrust of this requirement is that
that practices should only be published for that which the practices should only be published for that which the publisher
publisher has control, and should not meddle in what is has control, and should not meddle in what is ultimately the
ultimately the local policy of the receiver.] local policy of the receiver.
[Refs: Deployment Consideration 3] Refs: Deployment Consideration, Section 4.3.
5.4. Extensibility and Forward Compatibility Requirements 5.4. Extensibility and Forward Compatibility Requirements
1. SSP MUST NOT extend to any other protocol than DKIM for email at 1. SSP MUST NOT extend to any protocol other than DKIM for email at
this time. SSP SHOULD be extensible for protocols other than this time. SSP SHOULD be extensible for protocols other than
DKIM. DKIM.
[Refs: Deployment Consideration 7] Refs: Deployment Consideration, Section 4.7.
2. SSP MUST be able to add new Practices and Expectations within the 2. SSP MUST be able to add new practices and expectations within the
existing discovery/transport/practices in a backward compatible existing discovery/transport/practices in a backward compatible
fashion. fashion.
[Refs: Deployment Consideration 7] Refs: Deployment Consideration, Section 4.7.
6. Requirements for SSP Security 6. Requirements for SSP Security
1. SSP for a high-value domain is potentially a high-value DoS 1. SSP for a high-value domain is potentially a high-value DoS
target, especially since the unavailability of SSP's record could target, especially since the unavailability of SSP's record could
make unsigned messages less suspicious. make unsigned messages less suspicious.
2. SSP MUST NOT make highly leveraged amplification or make-work 2. SSP MUST NOT make highly leveraged amplification or make-work
attacks possible. In particular the work and message exchanges attacks possible. In particular, the work and message exchanges
involved MUST be order of a constant. involved MUST be order of a constant.
[Refs: Deployment Consideration 8] Refs: Deployment Consideration, Section 4.8.
3. SSP MUST have the ability for a domain holder to provide SSP's 3. SSP MUST have the ability for a domain holder to provide SSP's
data such that a receiver can determine that it is authentically data such that a receiver can determine that it is authentically
from the domain holder with a large degree of certainty. SSP may from the domain holder with a large degree of certainty. SSP may
provide means which provide less certainty in trade off for ease provide means that provide less certainty in trade off for ease
of deployment. of deployment.
[Refs: Deployment Consideration 8] Refs: Deployment Consideration, Section 4.8.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations 7. Security Considerations
This document defines requirements for a new protocol and the This document defines requirements for a new protocol and the
security related requirements are defined above. Since it is security related requirements are defined above. Since it is
expected that the new protocol will use the DNS as a basis for the expected that the new protocol will use the DNS as a basis for the
published SSP information, most if not all of the threats described published SSP information, most if not all of the threats described
in [RFC4686] will be applicable. in [RFC4686] will be applicable.
9. Acknowledgments 8. Acknowledgments
Dave Crocker and Jim Fenton provided substantial review of this Dave Crocker and Jim Fenton provided substantial review of this
document. Thanks also to Vijay Gurbani and David Harrington for document. Thanks also to Vijay Gurbani and David Harrington for
their helpful last call reviews. their helpful last call reviews.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
10.2. Informative References
Author's Address Author's Address
Michael Thomas Michael Thomas
Cisco Systems Cisco Systems
606 Sanchez St 606 Sanchez St
San Francisco, California 94114 San Francisco, California 94114
USA USA
Phone: +1-408-525-5386 Phone: +1-408-525-5386
Fax: +1-408-525-5386 Fax: +1-408-525-5386
Email: mat@cisco.com EMail: mat@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 24, line 44 skipping to change at line 653
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 95 change blocks. 
268 lines changed or deleted 219 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/