draft-ietf-dkim-ssp-requirements-04.txt   draft-ietf-dkim-ssp-requirements-05.txt 
DKIM Working Group M. Thomas DKIM Working Group M. Thomas
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational April 23, 2007 Intended status: Informational August 11, 2007
Expires: October 25, 2007 Expires: February 12, 2008
Requirements for a DKIM Signing Practices Protocol Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-04 draft-ietf-dkim-ssp-requirements-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 25, 2007. This Internet-Draft will expire on February 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
Practices . . . . . . . . . . . . . . . . . . . . . . . . 12 Practices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Deployment Consideration 7: Extensibility . . . . . . . . 12 4.7. Deployment Consideration 7: Extensibility . . . . . . . . 12
4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12 4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13 5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13
5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14 5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14
5.3. Practice and Expectation Requirements . . . . . . . . . . 14 5.3. Practice and Expectation Requirements . . . . . . . . . . 14
5.4. Extensibility and Forward Compatibility Requirements . . . 16 5.4. Extensibility and Forward Compatibility Requirements . . . 16
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 18 6. Requirements for SSP Security . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
DomainKeys Identified Mail [I-D.ietf-dkim-base]defines a message DomainKeys Identified Mail [RFC4871] defines a message level signing
level signing and verification mechanism for email. While a DKIM and verification mechanism for email. While a DKIM signed message
signed message speaks for itself, there is ambiguity if a message speaks for itself, there is ambiguity if a message doesn't have a
doesn't have a valid first party signature (ie, on behalf of the valid first party signature (ie, on behalf of the [RFC2822].From
RFC2822.From address): is this to be expected or not? For email this address): is this to be expected or not? For email this is an
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 which is inherent with systems be used to mount a bid down attack that is inherent with systems like
that allow optional authentication like email: if a receiver doesn't email that allow optional authentication: if a receiver doesn't know
know otherwise, it should not assume that the lack of a valid otherwise, it should not assume that the lack of a valid signature is
signature is exceptional without other information. Thus, an exceptional without other information. Thus, an attacker can take
attacker can take advantage of the ambiguity and simply not sign advantage of the ambiguity and simply not sign messages. If a
messages. If a protocol could be developed for a domain to publish protocol could be developed for a domain to publish its DKIM signing
its DKIM signing practices, a message verifier could take that into practices, a message verifier could take that into account when it
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: a Problem and Deployment Scenario
section which describes the problems that SSP is intended to address section which describes the problems that SSP is intended to address
as well as the deployment issues surrounding the base problems. The as well as the deployment issues surrounding the base problems. The
second section is the Requirements that arise because of those second section is the Requirements that arise because of those
scenarios. scenarios.
2. Definitions 2. Definitions
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 domain tag (d= or the more specific identity signature where the signing identity (the d= tag or the more
i= tag) matches the first party address. "Matches" in this specific identity i= tag) matches the first party address.
context is defined in [I-D.ietf-dkim-base] "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 third party address such as Sender or List-Id, etc. a header field address such as the contents of Sender or List-Id,
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. A practice should always be true when received by a sends.
topologically adjacent SMTP server.
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 non-topologically adjacent receiver. Practice for a receiver, in particular receivers that may be more
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.
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 tries to outline some usage scenarios considerations. This section outlines expected usage scenarios where
that it is expected that DKIM signing/verifying will take place in, DKIM signing/verifying will take place, and how a new protocol might
and how a new protocol might be helpful to clarify the relevance of help to clarify the relevance of DKIM-signed mail.
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 ability
ensured that all legitimate mail purporting to have come from that ensured that all legitimate mail purporting to have come from that
domain contains a valid DKIM signature. 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 that for a given domain. Thus, the receiver is at a disadvantage in not
it does not know if it should expect all mail to be signed from a knowing whether it should expect all mail to be signed from a given
given domain or not. This knowledge gap leads to a trivially domain or not. This knowledge gap leads to a trivially exploitable
exploitable bid-down attack where the attacker merely sends unsigned bid-down attack where the attacker merely sends unsigned mail; since
mail; since the receiver doesn't know the practices of the signing the receiver doesn't know the practices of the signing domain, it
domain, it cannot treat the message any more harshly for lack of a cannot treat the message any more harshly for lack of a valid
valid signature. signature.
An information service which allows a receiver to query for the An information service which 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 (eg 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 A sends to B with a missing or broken 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
DKIM first party signature from A with a missing or broken DKIM first party signature from Alice
2. B would like to know whether that is an expected state of 2. Domain Bob would like to know whether that is an expected state
affairs. of affairs.
3. A provides information that it signs all outgoing mail, but 3. Domain Alice provides information that it signs all outgoing
places no expectation on whether it will arrive with an intact mail, but places no expectation on whether it will arrive with an
first party signature. intact first party signature.
4. B could use this information to bias its filters to examines the 4. Domain Bob could use this information to bias its filters to
message with some suspicion. examines 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 the target of phishing attacks. In particular, many domains is currently the target of phishing attacks. In particular,
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 kind of revealing sensitive information. Domain holders sending this mail
mail would like the ability to give an enhanced guarantee that mail would like the ability to give an enhanced guarantee that mail sent
sent in their 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 can know that the domain not only signs all of its mail, but
also feels it essential that legitimate mail must have its first also feels it essential that legitimate mail must have its first
party signatures survive transit. A receiver with the knowledge of party signatures survive transit. A receiver with the knowledge of
the sender's expectations in hand might choose to process messages the sender's expectations in hand might choose to process messages
not conforming to the published practices in a special manner. Note not conforming to the published practices in a special manner. Note
that the ability to state an enhanced guarantee of a valid signature that the ability to state an enhanced guarantee of a valid signature
means that senders should expect mail that traverses modifying means that senders should expect mail that traverses modifying
intermediaries (eg, mailing lists, etc) will be likely be quarantined intermediaries (eg, mailing lists, etc) will be likely be quarantined
or deleted, thus this scenario is more narrow than problem scenario or deleted, thus this scenario is more narrow than problem scenario
1. 1.
[Informative Note: in terms of a receiving filter, one may choose [Informative Note: a receiving filter may choose to treat scenario
to treat scenario 2 much more harshly than scenario 1; where 2 much more harshly than scenario 1; where scenario 1 looks odd,
scenario 1 looks odd, scenario 2 looks like something is very scenario 2 looks like something is very wrong]
wrong]
1. Mail with a [RFC2822].From A purportedly sends to B with a 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
missing or broken first party DKIM signature from A with a missing or broken first party DKIM signature from domain
2. B would like to know whether that is an expected state of Alice
affairs. 2. Domain Bob would like to know whether that is an expected state
of affairs.
3. A provides information that it signs all outgoing mail, but 3. Domain Alice provides information that it signs all outgoing
places an expectation that it should arrive with an intact first mail, and furthermore places an expectation that it should arrive
party signature, and that the receiver should be much more wary with an intact first party signature, and that the receiver
if it does not. should be much more wary if it does not.
4. B could use this information to bias its filters such that it 4. Domain Bob could use this information to bias its filters such
examines the message with great suspicion. that it examines the message with great suspicion.
4. SSP Deployment Considerations 4. SSP Deployment Considerations
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
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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 A SSP client will perform lookups on incoming mail streams to provide
the information as proposed in the problem scenarios. The domain the information as proposed in the problem scenarios. The domain
part of the first address of the RFC2822.From will form the basis to part of the first address of the [RFC2822].From will form the basis
fetch the published information. A trivial attack to circumvent to fetch the published information. A trivial attack to circumvent
finding the published information can be mounted by simply using a finding the published information can be mounted by simply using a
subdomain of the parent domain which doesn't have published subdomain of the parent domain which 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 SSP's information service. Thus, it would be advantageous for SSP
to not only cover a given domain, but all subdomains of that domain to not only cover a given domain, but all subdomains of that domain
as well. 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, Alice sends a DKIM signed message with world of today. For example, domain Alice sends a DKIM signed
a published practice of signing all messages to Bob's mailing list. message with a published practice of signing all messages to domain
Bob, being a good net citizen, wants to be able to take his part of Bob's mailing list. Bob, being a good net citizen, wants to be able
the responsibility of the message in question, so he DKIM signs the to take his part of the responsibility of the message in question, so
message, perhaps corresponding to the Sender address. he DKIM signs the message, perhaps corresponding to the Sender
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 are not friendly to DKIM
first party signatures (ie, break them) can be potentially assessed first party signatures (ie, break them) can be potentially assessed
by the receiver based on the receiver's opinion of the signing by the receiver based on the receiver's opinion of the signing
domains that actually survived. domains that actually survived.
skipping to change at page 12, line 8 skipping to change at page 12, line 9
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 a 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 into
two main scenarios, the first of which are large, well known domains two main scenarios, the first of which are large, well known domains
who are in constant contact with one another. In this case caching who are in constant contact with one another. In this case caching
of records is essential for performance, including the caching of the of records is essential for performance, including the caching of the
non-existence of records (ie, negative caching). non-existence of records (ie, 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 sadly a vector for those sending with the case of vanity domains, and unfortunately a vector for those
mail for anti-social reasons. In this case we'd like the message sending mail for anti-social reasons. In this case we'd like the
exchange burden to SSP querier to be low, since many of the lookups message exchange burden to SSP querier to be low, since many of the
will not provide a useful answer. Likewise, it would be advantageous lookups will not provide a useful answer. Likewise, it would be
to have upstream caching here as well so that, say, a mailing list advantageous to have upstream caching here as well so that, say, a
exploder on a small domain does not result in an explosion of queries mailing list exploder on a small domain does not result in an
back at the root and authoritative server for the small domain. explosion of queries back at the root and authoritative server for
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 which is also intuitive to the human inspectors.
4.7. Deployment Consideration 7: Extensibility 4.7. Deployment Consideration 7: Extensibility
skipping to change at page 13, line 19 skipping to change at page 13, line 19
requirements that a candidate protocol must provide. It should also requirements that a candidate protocol must provide. It should also
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 responsive
within a small, deterministic number of query exchanges. within a small, deterministic number of message exchanges under
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 2, 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 records of different protocols residing at the lead to multiple resource records of the same type for different
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 same type within a common DNS leaf. Hence, uniquely the same type within a common DNS leaf. Hence, uniquely
defined leaf names or uniquely defined resource record types defined leaf names or uniquely defined resource record types
will ensure unambiguous reference.] will ensure unambiguous reference.]
[Refs: Deployment Consideration 2] [Refs: Deployment Consideration 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. The process of obtaining the but all of its subdomains as well. It is recognized that there
parent domain's practices MUST complete in a deterministic number is some reasonable doubt about the feasibility of a widely
of steps. It is recognized that there is some reasonable doubt accepted solution to this requirement. If the working group does
about the feasibility of a widely accepted solution to this not achieve rough consensus on a solution, it MUST document the
requirement. If the working group does not achieve rough relevant security considerations in the protocol specification.
consensus on a solution, it MUST document the relevant security
considerations in the protocol specification.
[Refs: Deployment Considerations 2, 5 [Refs: Deployment Considerations 2, 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 an internet-
based message exchange. There are multiple requirements for this based message exchange. There are multiple requirements for this
lower layer service: lower 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 (eg, TCP, UDP).
[Refs: Deployment Considerations 5, 7] [Refs: Deployment Considerations 5, 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
packets involved MUST be low (order of 1 or 2 exchanges). messages involved MUST be low (less than three message exchanges
not counting retransmissions or other exceptional conditions).
[Refs: Deployment Consideration 5] [Refs: Deployment Consideration 5]
3. If the infrastructure doesn't provide caching (ala DNS), the 3. If the infrastructure doesn't provide caching (ala DNS), the
records retrieved MUST provide initiators the ability maintain records retrieved MUST provide initiators the ability maintain
their own cache. Existing caching infrastructure is, however, their own cache. Existing caching infrastructure is, however,
highly desirable. highly desirable.
[Refs: Deployment Consideration 5] [Refs: Deployment Consideration 5]
skipping to change at page 14, line 42 skipping to change at page 14, line 43
supported for high availability supported for high availability
[Refs: Deployment Considerations 5, 7] [Refs: Deployment Considerations 5, 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 a Practice is a statement according to
the [RFC2822].From domain holder of externally verifiable behavior in the [RFC2822].From domain holder of externally verifiable behavior in
the email messages it sends. As an example, a Practice might be the email messages it sends. As an example, a Practice might be
defined that all email messages will contain a DKIM signature defined that all email messages will contain a DKIM signature
corresponding to the RFC2822.From address. Since there is a corresponding to the [RFC2822].From address. Since there is a
possibility of alteration between what a sender sends and a receiver possibility of alteration between what a sender sends and a receiver
examines, an Expectation combines with a Practice to convey what the examines, an Expectation combines with a Practice to convey what the
RFC2822.From domain considers the likely outcome of the survivability [RFC2822].From domain considers the likely outcome of the
of the Practice at a receiver. For example, a Practice that a valid survivability of the Practice at a receiver. For example, a Practice
DKIM for the RFC2822.From address is present when it is sent from the that a valid DKIM for the [RFC2822].From address is present when it
domain, and an Expectation that it will remain present and valid for is sent from the domain, and an Expectation that it will remain
all receivers whether topologically adjacent or not. present and valid for all receivers whether topologically 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,2]
2. SSP MUST provide a concise linkage between the [RFC2822].From 2. SSP MUST provide a concise linkage between the [RFC2822].From
and the identity in the DKIM i= tag, or its default if it is and the identity in the DKIM i= tag, or its default if it is
skipping to change at page 18, line 5 skipping to change at page 18, line 5
DKIM. DKIM.
[Refs: Deployment Consideration 7] [Refs: Deployment Consideration 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 7]
6. Security Requirements 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 8]
skipping to change at page 20, line 8 skipping to change at page 20, line 8
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. 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. There is an security related requirements are defined above. Since it is
expectation that SSP will not always be required to have source expected that the new protocol will use the DNS as a basis for the
authentication of the practices information which is noteworthy. published SSP information, most if not all of the threats described
in [RFC4686] will be applicable.
9. Acknowledgments 9. Acknowledgments
Dave Crocker and Jim Fenton provided substantial review of this Dave Crocker and Jim Fenton provided substantial review of this
document. document. Thanks also to Vijay Gurbani and David Harrington for
their helpful last call reviews.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-04 (work in progress),
July 2006.
[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., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
10.2. Informative References 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
 End of changes. 38 change blocks. 
108 lines changed or deleted 115 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/