< 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
			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 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 (a la 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]
	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 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
	Phone: +1-408-525-5386		Phone: +1-408-525-5386
End of changes. 40 change blocks.
	109 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/