draft-ietf-dkim-ssp-requirements-02.txt   draft-ietf-dkim-ssp-requirements-03.txt 
DKIM Working Group M. Thomas DKIM Working Group M. Thomas
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational September 2006 Intended status: Informational March 6, 2007
Expires: March 5, 2007 Expires: September 7, 2007
Requirements for a DKIM Signing Practices Protocol Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-02 draft-ietf-dkim-ssp-requirements-03
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 March 5, 2007. This Internet-Draft will expire on September 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
cryptographic mechanism for domains to assert responsibility for the for domains to assert responsibility for the messages they handle. A
messages they handle. A related mechanism would allow an related mechanism will allow an administrator to publish various
administrator to publish various statements about their DKIM signing statements about their DKIM signing practices. This document defines
practices. This draft defines the requirement for this mechanism. requirements for this mechanism.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 7
3.1. Problem Scenario 1: All Mail Signed with DKIM . . . . . . 7
4. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 8 3.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 8
4.1. Problem Scenario 1: All Mail Signed with DKIM . . . . . . 8
4.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 9
4.3. Problem Scenario 3: Domain Sends No Mail . . . . . . . . . 10
5. SSP Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11 4. SSP Deployment Scenarios . . . . . . . . . . . . . . . . . . . 10
5.1. Deployment Scenario 1: Outsourced Signing . . . . . . . . 11 4.1. Deployment Scenario 1: Outsourced Signing . . . . . . . . 10
5.2. Deployment Scenario 2: Determinism in Lookup Mechanism . . 11 4.2. Deployment Scenario 2: Determinism in Lookup Mechanism
5.3. Deployment Scenario 3: Resent Original Mail . . . . . . . 11 and Subdomain Coverage . . . . . . . . . . . . . . . . . . 10
5.4. Deployment Scenario 4: Incremental Deployment of 4.3. Deployment Scenario 3: Resent Original Mail . . . . . . . 10
Signing . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Deployment Scenario 4: Incremental Deployment of
5.5. Deployment Scenario 5: Transport Scenarios . . . . . . . . 12 Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Deployment Scenario 6: Human Legibility of Practices . . . 13 4.5. Deployment Scenario 5: Transport Scenarios . . . . . . . . 11
5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks . . 13 4.6. Deployment Scenario 6: Human Legibility of Practices . . . 12
5.8. Deployment Scenario 8: Extensibility . . . . . . . . . . . 13 4.7. Deployment Scenario 7: Cryptographic Downgrade Attacks . . 12
5.9. Deployment Scenario 9: Security . . . . . . . . . . . . . 13 4.8. Deployment Scenario 8: Extensibility . . . . . . . . . . . 12
4.9. Deployment Scenario 9: Security . . . . . . . . . . . . . 12
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 15 5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13
6.2. Transport requirements . . . . . . . . . . . . . . . . . . 16 5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14
6.3. Practice and Expectation Requirements . . . . . . . . . . 16 5.3. Practice and Expectation Requirements . . . . . . . . . . 14
6.4. Extensibility and Forward Compatibility Requirements . . . 19 5.4. Extensibility and Forward Compatibility Requirements . . . 17
7. Security Requirements . . . . . . . . . . . . . . . . . . . . 20 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Preface DomainKeys Identified Mail [I-D.ietf-dkim-base]defines a message
level signing and verification mechanism for email. While a DKIM
signed message speaks for itself, there is ambiguity if a message
doesn't have a valid first party signature: is this to be expected or
not?. For email this is an especially difficult problem since there
is no expectation of a priori knowledge of a sending domain's
practices. This ambiguity can be used to mount a bid down attack
which is inherent with systems that allow optional authentication
like email: if a receiver doesn't know otherwise, it should not
assume that the lack of a valid signature is a priori invalid. Thus,
an attacker can take advantage of the ambiguity and simply not sign
messages. If a protocol could be developed for a domain to publish
its DKIM signing practices, a message verifier could take that into
account when it receives an unsigned piece of email.
The purpose of this draft is get out into the open a range of issues This document defines the requirements for a mechanism that permits
related to the perceived need for a signing practices information the publication of Sender Signing Practices (SSP). The document is
service primarily focused on DKIM. This document is intended to organized into two main sections: a Problem and Deployment Scenario
document well-agreed upon problems and requirements, in addition to section which describes the problems that SSP is intended to address
less well-agreed upon requirements in an attempt to capture the issue as well as the deployment issues surrounding the base problems. The
as well as generalize the requirement as much as possible. These second section is the Requirements that arise because of those
latter requirements will be noted as "[PROVISIONAL]" to indicate that scenarios.
there is not yet solid consensus, or that the problem is not well
understood. A winnowing process is envisioned where the more
difficult and/or speculative problems/requirement will be eliminated
unless concrete problems with proven constituencies can be
demonstrated, along with reasonable plausibility that they do not
contradict more well agreed upon requirements.
2. Definitions 2. Definitions
o Domain Holder: the entity that ultimately controls the contents of o Domain Holder: the entity that controls the contents of the DNS
the DNS subtree starting at the domain, either directly or by subtree starting at the domain, either directly or by delegation
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 domain tag (d= or the more specific identity
i= tag) matches the first party address. "Matches" in this i= tag) matches the first party address. "Matches" in this
context is defined in [I-D.ietf-dkim-base] context is defined in [I-D.ietf-dkim-base]
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 does is not required to that a DKIM third party signature is not required to correspond to
correspond to a third party address such as Sender or Listid, etc. a third party address such as Sender or Listid, etc.
o DKIM Signer Complete: the state where the domain holder believes
that all legitimate mail purportedly from the domain was sent with
a valid DKIM signature.
o The Protocol: in this document, The Protocol is used as
placeholder for a protocol that will meet the requirements set in
this draft.
3. Introduction
The DomainKeys Identified Mail working group is chartered to create a o Practice: a statement according to the [RFC2822].From domain
base signing mechanism for email. This work is contained in holder of externally verifiable behavior in the email messages it
[I-D.ietf-dkim-base]. In addition there are two other documents sends. A practice should always be true when received by a
[I-D.ietf-dkim-overview] and [I-D.ietf-dkim-threats] which give an topologically adjacent SMTP.
overview and a threat analysis of the chartered work. This draft
reflects the requirements for the last part of the chartered work to
define a protocol to publish DKIM signing practices.
While the base signing document defines a mechanism for signing and o Expectation: an Expectation combines with a Practice to convey
verifying DKIM signatures, there has been a great deal of interest in what the domain holder considers the likely survivability of the
a signing practices protocol. The most pressing case seems to be the Practice for a non-topologically adjacent receiver.
bid down attack inherent with almost all systems that allow optional
authentication: how does a receiver know whether or not it should
expect a message to contain authentication information? For email
this is an especially difficult problem since there is generally no a
priori knowledge of a sending domain's practices. If a protocol
could be developed for a domain to publish its DKIM signing
practices, a message verifier could take that into account when it
receives a unsigned piece of email.
This draft is organized into two main sections: a Problem and o DKIM Signing Complete: a Practice where the domain holder asserts
Deployment Scenario section which describes the problems that The that all legitimate mail will be sent with a valid First Party
Protocol is intended to address as well as the deployment issues Signature.
surrounding the base problems. The second section is the
Requirements that arise because of those scenarios.
4. SSP Problem Scenarios 3. SSP Problem Scenarios
The email world is a diverse place with many deployment scenarios. The email world is a diverse place with many deployment scenarios.
This section tries to outline some usage scenarios that it is This section tries to outline some usage scenarios that it is
expected that DKIM signing/verifying will take place in, and how a expected that DKIM signing/verifying will take place in, and how a
new protocol might be helpful to clarify the relevance of DKIM signed new protocol might be helpful to clarify the relevance of DKIM signed
mail. mail.
4.1. Problem Scenario 1: All Mail Signed with DKIM 3.1. Problem Scenario 1: 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
insured that all mail legitimately purporting to have come from that insured that all mail legitimately 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, or what their expectations are for unsigned mail. for a given domain, or what their expectations are for unsigned mail.
Thus the receiver is at a disadvantage in that it does not know if it Thus the receiver is at a disadvantage in that it does not know if it
should expect mail to be signed from a given domain or not. This should expect mail to be signed from a given domain or not. This
knowledge gap leads to a trivially exploitable bid-down attack where knowledge gap leads to a trivially exploitable bid-down attack where
the attacker merely sends unsigned mail; since the receiver doesn't the attacker merely sends unsigned mail; since the receiver doesn't
know the practices of the signing domain, it cannot treat the message know the practices of the signing domain, it cannot treat the message
any more harshly for lack of a valid signature. any more harshly for lack of a valid signature.
An information service which allowed a receiver to query for the An information service which allowed a receiver to query for the
practices and expectations of the sending domain when no valid practices and expectations of the first party domain when no valid
signature is found could be useful in closing this gap. A receiver first party signature is found could be useful in closing this gap.
could use this information to treat such questionable mail with A receiver could use this information to treat such questionable mail
varying degrees of prejudice. with varying degrees of prejudice.
Note that for the foreseeable future, DKIM signature breakage for Note that for the foreseeable future, unrestricted use patterns of
unrestricted use patterns (eg where users are members of mailing mail (eg where users may be members of mailing lists, etc) will
lists, etc) will likely suffer occasional non-malicious signature likely suffer occasional non-malicious signature failure in transit.
failure in transit. While probably not a large percentage of total While probably not a large percentage of total traffic, the kind of
traffic, the kind (quality) of breakage may be a significant concern breakage may be a significant concern for those usage patterns. This
for those usage patterns. This scenario defines where the sender scenario defines where the sender cannot set any expectation as to
cannot set any expectation as to whether an individual message will whether an individual message will arrive intact.
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 filters against unsigned or damaged in transit mail. mail and bias filters against unsigned or damaged in transit mail.
This information should not be expected to be used in a binary yes/no 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 filtering fashion, but instead as a data point among others in a filtering
system. system.
1. Mail with a [RFC2822].From A purportedly sends to B with a 1. Mail with a [RFC2822].From A purportedly sends to B with a
missing or broken DKIM signature from A missing or broken DKIM first party signature from A
2. B would like to know whether that is an expected state of 2. B would like to know whether that is an expected state of
affairs. affairs.
3. A provides information that it signs all outgoing mail, but 3. A provides information that it signs all outgoing mail, but
places no expectation on whether it will arrive with an intact places no expectation on whether it will arrive with an intact
signature. first party signature.
4. B could use this information to bias its filters such that it 4. B could use this information to bias its filters such that it
looks somewhat more suspicious. looks somewhat more suspicious.
4.2. Problem Scenario 2: Illegitimate Domain Name Use 3.2. Problem Scenario 2: Illegitimate Domain Name Use
There seems to be a class of mail -- mostly transactional mail from A class of mail typified by transactional mail from high value
high value domains -- that are the target of phishing attacks. In domains is the target of phishing attacks. In particular, many
particular, many phishing scams forge the [RFC2822].From address in phishing scams forge the [RFC2822].From address in addition to
addition to spoofing much of the content to trick unsuspecting users spoofing much of the content to trick unsuspecting users into
into revealing sensitive information. Domain holders sending this revealing sensitive information. Domain holders sending this kind of
kind of mail would like the ability to give an enhanced guarantee mail would like the ability to give an enhanced guarantee that mail
that mail sent in their name should always arrive with the provable sent in their name should always arrive with the proof that the
consent of the domain holder. domain holder consented to its transmission. That is, the message
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 also expects that legitimate mail from the all of its mail, but places a very high value on the receipt of a
domain will be received with a valid signature is quite interesting. valid first party signature from that domain is helpful. Hence a
This assertion from the signing domain is quite a bit stronger than receiver can know that the domain not only signs all of its mail, but
the assertion in Problem Scenario 1; even though a signer can never also feels it essential that legitimate mail must have its first
know the true path mail will take before delivery, the implication is party signatures survive transit. A receiver with the knowledge of
that if the message is lacking a valid signature the message is the sender's expectations in hand might choose to process messages
either malicious or is the responsibility of the signing domain to not conforming to the published practices in a special manner.
avoid whatever broke the signature.
[Informative Note: in terms of a receiving filter, one may choose [Informative Note: in terms of a receiving filter, one may choose
to treat scenario 2 much more harshly than scenario 1; where to treat scenario 2 much more harshly than scenario 1; where
scenario 1 looks odd, scenario 2 looks like something is very scenario 1 looks odd, 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 A purportedly sends to B with a
missing or broken DKIM signature from A missing or broken first party DKIM signature from A
2. B would like to know whether that is an expected state of 2. B would like to know whether that is an expected state of
affairs. affairs.
3. A provides information that it signs all outgoing mail, but 3. A provides information that it signs all outgoing mail, but
places an expectation that it should arrive with an intact places an expectation that it should arrive with an intact first
signature, and that the receiver should be suspicious if it does party signature, and that the receiver should be suspicious if it
not. does not.
4. B could use this information to bias its filters such that it 4. B could use this information to bias its filters such that it
looks much more suspicious. looks much more suspicious.
4.3. Problem Scenario 3: Domain Sends No Mail 4. SSP Deployment Scenarios
A domain may not intend to send mail at all. In such a case, it
could be advantageous for a receiver to know the domain's intent and
would be likely to treat such mail very suspiciously. It has been
noted that a solution to Problem Scenario 2 could potentially be used
to emulate this practice. In reality, they are close but not
precisely the same semantics. That is, a piece of email purporting
to come from a domain which claims to send none is illegitimate on
its face, whereas there may be some lingering doubt with Problem
Scenario 2 given the possibility in deployments between whether one
should publish scenario 1 and 2, etc.
5. SSP Deployment Scenarios
Given the problems enumerated above for which we'd like The Protocol Given the problems enumerated above for which we'd like SSP to
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 The Protocol would provide. service that SSP would provide.
5.1. Deployment Scenario 1: Outsourced Signing 4.1. Deployment Scenario 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 delegate to other entities the ability to
sign for the domain holder. One obvious use scenario is a domain 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.
5.2. Deployment Scenario 2: Determinism in Lookup Mechanism 4.2. Deployment Scenario 2: Determinism in Lookup Mechanism and
Subdomain Coverage
The Protocol's client will generally be deployed on incoming mail
streams to provide the information as proposed in the problem
scenarios. As such, it is envisioned that the RFC2822.From address
would be used as a basis for the lookup. In particular, the domain
part of the address would be consulted in some manner to fetch the
published information. There is a fairly trivial attack against a
naive use of this algorithm which is called the subdomain attack:
that is, a domain needs to not only publish a policy for a given DNS
label it controls, but it also may need to protect all subdomains of
that label as well. If this characteristic is not met, an attacker
would need only create a possibly fictitious subdomain which was not
covered by The Protocol's information service
In widening the scope to have the possibility of all subdomains SSP's client will generally be deployed on incoming mail streams to
inherit the parent practice, a number of algorithms could be employed provide the information as proposed in the problem scenarios. The
-- all seemingly with their own set of engineering tradeoffs. A RFC2822.From address will be used as a basis for the lookup. More
common theme in the production of this draft was that the number of precisely the domain part of the first address of the RFC2822.From
lookups, on average should be small, and that the discovery process will form the trust basis to fetch the published information. A
should always be bound to some small finite number of queries. trivial attack to circumvent finding the published information could
be mounted by simply using a subdomain of the parent which doesn't
have published information. This attack is called the subdomain
attack: that is, a domain needs to not only publish a policy for a
given DNS label it controls, but it also may need to protect all
subdomains of that label as well. If this characteristic is not met,
an attacker would need only create a possibly fictitious subdomain
which was not covered by SSP's information service. Thus, it would
be advantageous for The Protocol to not only cover a given domain,
but all subdomains of that domain as well.
5.3. Deployment Scenario 3: Resent Original Mail 4.3. Deployment Scenario 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, Alice sends a DKIM signed message with
a published practice of signing all messages to Bob's mailing list. a published practice of signing all messages to Bob's mailing list.
Bob, being a good net citizen, wants to be able to take his part of Bob, being a good net citizen, wants to be able to take his part of
the responsibility of the message in question, so he DKIM signs the the responsibility of the message in question, so he DKIM signs the
message, perhaps corresponding to the Sender address. 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.
5.4. Deployment Scenario 4: Incremental Deployment of Signing 4.4. Deployment Scenario 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, outsourced
vendors sending on its behalf, etc. This leaves open an exploit that vendors sending on its behalf, etc. This leaves open an exploit that
high-value mail such as in Problem Scenario 2 must be classified to high-value mail such as in Problem Scenario 2 must be classified to
the least common denominator of the published practices. It would be the least common denominator of the published practices. It would be
desirable to allow a domain holder to publish a list of exceptions desirable to allow a domain holder to publish a list of exceptions
which would have a stronger practices statement. which would have a stronger practices statement.
skipping to change at page 12, line 41 skipping to change at page 11, line 39
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 which 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 a strong practice while *@bigbank.example.com could would publish constrained practices while
publish a more permissive practice. corporateusers.bigbank.example.com might publish more permissive
practices.
5.5. Deployment Scenario 5: Transport Scenarios 4.5. Deployment Scenario 5: Transport Scenarios
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 The Protocol is likely to listener to receive mail. Thus the use of SSP is likely to fall into
fall into two main scenarios, the first of which are large, well two main scenarios, the first of which are large, well known domains
known domains who are in constant contact with one another. In this who are in constant contact with one another. In this case caching
case caching of records is essential for performance, including the of records is essential for performance, including the caching of 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 sadly a vector for those sending
mail for anti-social reasons. In this case we'd like the burden to mail for anti-social reasons. In this case we'd like the burden to
The Protocol querier to be low, since many of the lookups will not SSP querier to be low, since many of the lookups will not provide a
provide a useful answer. Likewise, it would be advantageous to have useful answer. Likewise, it would be advantageous to have upstream
upstream caching here as well so that, say, a mailing list exploder caching here as well so that, say, a mailing list exploder on a small
on a small domain does not result in an explosion of queries back at domain does not result in an explosion of queries back at the root
the root server for the small domain. server for the small domain.
5.6. Deployment Scenario 6: Human Legibility of Practices 4.6. Deployment Scenario 6: Human Legibility of Practices
While The Protocol 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.
[Author's $.02: it's been amply demonstrated that simple human 4.7. Deployment Scenario 7: Cryptographic Downgrade Attacks
readable labels are often misconstrued. Opaque symbols do have
the advantage that you need to consult the definition to determine
its meaning rather than just intuiting what it "ought" to mean.
/mat]
5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks
There is a downgrade attack possible where a DKIM signature is hashed There is a downgrade attack possible when a DKIM signature is hashed
with a previously acceptable but now insecure hash algorithm. This with a previously acceptable but now insecure hash algorithm. This
could allow attackers to send their chosen text which is apparently could allow attackers to send their chosen text which is apparently
signed by the targeted domain. It would be advantageous for a domain signed by the targeted domain. It would be advantageous for a domain
to publish what the allowable signing/hashing algorithms are to to publish what the allowable signing/hashing algorithms are to
prevent this downgrade attack. prevent this downgrade attack.
5.8. Deployment Scenario 8: Extensibility 4.8. Deployment Scenario 8: 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.
5.9. Deployment Scenario 9: Security 4.9. Deployment Scenario 9: Security
The protocol must be able to withstand life in a hostile open SSP must be able to withstand life in a hostile open internet
internet environment. These include DoS attacks, and especially DoS environment. These include DoS attacks, and especially DoS attacks
attacks that leverage themselves through amplification inherent in that leverage themselves through amplification inherent in the
the protocol. In addition, while a useful protocol may be built protocol. In addition, while a useful protocol may be built without
without strong source authentication provided by the information strong source authentication provided by the information service, a
service, a path to strong source authentication should be provided by path to strong source authentication should be provided by the
the protocol, or underlying protocols. protocol, or underlying protocols.
6. Requirements 5. Requirements
This section defines the requirements for The Protocol. As with most This section defines the requirements for SSP. As with most
requirements drafts, these requirements define the MINIMUM requirements documents, these requirements define the MINIMUM
requirements that a candidate protocol must provide. It should also requirements that a candidate protocol must provide. It should also
be noted that The Protocol must fulfill all of the requirements. be noted that SSP must fulfill all of the requirements.
[Informative Note: it's not clear to the author that all of the
provisional requirements can fulfill the harder requirements. If
this is determined to be true, the provisional requirement should
either be dropped or the harder requirements revised]
6.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. The Protocol's information is in the [rfc2822].From field. SSP's information is associated
associated with the author's domain name and is published with the author's domain name and is published subordinate to
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 The Protocol's information must provide a definitive supplying SSP's information MUST provide a definitive responsive
responsive within a small, deterministic number of query within a small, deterministic number of query exchanges.
exchanges.
[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 Scenario 2] [Refs: Deployment Scenario 2]
3. The Protocol's publishing mechanism MUST be defined to produce 3. SSP's publishing mechanism MUST be defined such that it does not
unambiguous semantics, particularly with respect to other lead to multiple records of different protocols residing at the
information that might share the publication mechanism. same location.
[Informative note: An example of ambiguity is sharing resource [Informative note: An example is multiple resource record of
record types 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 Scenario 2] [Refs: Deployment Scenario 2]
6.2. Transport requirements 4. SSP must be capable of providing coverage for not only the domain
but all of its subdomains as well. If all subdomains cannot be
directly associated with the parent's information, the protocol
MUST be able to communicate that the domain name is suspicious.
The process of obtaining the parent domain's practices MUST
complete in a deterministic number of steps, preferably few. In
widening the scope to have the possibility of all subdomains
inherit the parent practice, a number of algorithms could be
employed -- all seemingly with their own set of engineering
tradeoffs. A common theme in the production of this document was
that the number of lookups, on average should be small, and that
the discovery process should always be bound to some small finite
number of queries.
[Refs: Deployment Scenario 2
5.2. SSP Transport Requirements
The publication and query mechanism will operate over the Internet
message exchange. This lower layer service must exhibit basic
characteristics:
1. Widespread deployment of the transport layer would be highly 1. Widespread deployment of the transport layer would be highly
desirable, especially if riding on top of a true transport layer desirable, especially if riding on top of a true transport layer
(eg, TCP, UDP). (eg, TCP, UDP).
[Refs: Deployment Scenario 5, 8] [Refs: Deployment Scenario 5, 8]
2. A low-cost query/response in terms of latency time and the number 2. A low-cost query/response in terms of latency time and the number
of packets involved is highly desirable. of packets involved is highly desirable.
skipping to change at page 16, line 30 skipping to change at page 14, line 41
verifiers to maintain their own caches. Existing caching verifiers to maintain their own caches. Existing caching
infrastructure is, however, highly desirable. infrastructure is, however, highly desirable.
[Refs: Deployment Scenario 5] [Refs: Deployment Scenario 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 Scenario 5, 8] [Refs: Deployment Scenario 5, 8]
6.3. Practice and Expectation Requirements 5.3. Practice and Expectation Requirements
In this section, a Practice is defined as a true statement according As stated in the definitions a Practice is a statement according to
to the [RFC2822].From domain holder of its intended externally the [RFC2822].From domain holder of externally verifiable behavior in
visible behavior. An Expectation combines with a Practice to convey the email messages it sends. As a silly example, a Practice might be
what the domain holder considers the likely outcome of the defined that all email messages will contain an X-Silly header.
survivability of the Practice for a receiver. For example, a Since there is a possibility of alteration between what a sender
Practice that X is true when it leaves the domain, and an Expectation sends and a receiver examines, an Expectation combines with a
that it will|will-not|may|may-not remain true for some/all receivers. Practice to convey what the domain holder considers the likely
outcome of the survivability of the Practice for at a receiver. For
example, a Practice that X-Silly is present when it is sent from the
domain, and an Expectation that it will remain present for receivers
whether topologically adjacent or not.
1. The Protocol MUST be able to make Practices and Expectation 1. SSP MUST be able to make Practices and Expectation assertions
assertions about the [RFC2822].From address in the context of about the [RFC2822].From address in the context of DKIM. SSP
DKIM. The Protocol will not make assertions about other will not make assertions about other addresses for DKIM at this
addresses for DKIM at this time. time.
[Refs: Problem Scenario 1,2] [Refs: Problem Scenario 1,2]
2. [PROVISIONAL] The Protocol MUST be able to publish a Practice 2. SSP MUST provide a concise linkage between the [RFC2822].From
which is indicative that domain doesn't send mail. and the identity in the DKIM i= tag, or its default if it is
missing in the signature. That is, SSP MUST precisely define
[Refs: Problem Scenario 3] the semantics of what qualifies as a First Party Signature.
3. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to
publish such a practice.
[INFORMATIVE NOTE: there seems to be widespread consensus
that a "neutral" or "I sign some mail" practice is useless to
receivers. However, a null practice may help to cut short
the policy lookup mechanism if it's published, and if that's
the case it seems worthwhile. Also, a null policy may have
some forensic utility, such as gaging the number of domains
considering/using DKIM for example.]
[Refs: Deployment Scenario 2] [Refs: Problem Scenario 1,2]
4. The Protocol MUST be able to publish a Practice that the 3. SSP MUST be able to publish a Practice that the domain's signing
domain's signing behavior is "DKIM Signing Complete" behavior is "DKIM Signing Complete". That is, all messages were
transmitted with a valid first party signature.
[Refs: Problem Scenario 1] [Refs: Problem Scenario 1]
5. The Protocol MUST be able to publish an Expectation that a 4. SSP MUST be able to publish an Expectation that a verifiable
verifiable First Party DKIM Signature should be expected on first party DKIM Signature should be expected on receipt of a
receipt of a message. message.
[Refs: Problem Scenario 2] [Refs: Problem Scenario 2]
6. Practices and Expectations MUST be presented in the Protocol 5. Practices and Expectations MUST be presented in SSP syntax using
syntax using as intuitive a descriptor as possible. For as intuitive a descriptor as possible. For example, p=? would
example, p=? would be better represented as p=unknown. be better represented as p=unknown.
[Refs: Deployment Scenario 6] [Refs: Deployment Scenario 6]
7. The Protocol MUST NOT invent a different means of allowing 6. Because DKIM uses DNS to store selectors, there is always the
affiliated parties to sign on a domain's behalf. Because DKIM ability for a domain holder to delegate all or parts of the
uses DNS to store selectors, there is always the ability for a _domainkey subdomain to an affiliated party of the domain
domain holder to delegate all or parts of the _domainkey holder's choosing. That is, the domain holder may be able to
subdomain to an affiliated party of the domain holder's set a NS record for _domainkey.example.com to, say, an email
choosing. That is, the domain holder may be able to set a NS provider who manages that namespace. There is also the ability
record for _domainkey.example.com to, say, an email provider who for the domain holder to partition its namespace into subdomains
manages that namespace. There is also the ability for the to further constrain third parties. For example, a domain
domain holder to partition its namespace into subdomains to
further constrain how third parties. For example, a domain
holder could delegate only _domainkey.benefits.example.com to a holder could delegate only _domainkey.benefits.example.com to a
third party to constrain the third party to only be able to third party to constrain the third party to only be able to
produce valid signatures in the benefits.example.com subdomain. produce valid signatures in the benefits.example.com subdomain.
Last, a domain holder can even use CNAME's to delegate Last, a domain holder can even use CNAME's to delegate
individual leaf nodes. individual leaf nodes. Thus SSP need not invent a different
means of allowing affiliated parties to sign on a domain's
8. [PROVISIONAL] The protocol MUST have the ability to provide behalf at this time.
practices and expectations keyed off of the local part of the
[RFC2822].From address. As with all provisional requirements,
this requirement must not be in conflict with other
requirements, including DNS considerations, etc.
[INFORMATIVE NOTE: this requirement seems to have rather weak
support. It's mainly been added so that it can be issue-
tracked. /mat]
[Refs: Deployment Scenario 4]
9. 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 to the receiver's local policy. In particular, a factor to the receiver's local policy. In particular, a
Practice or Expectation MUST NOT mandate any disposition stance Practice or Expectation MUST NOT mandate any disposition stance
on the receiver. on the receiver.
[Refs: Problem Scenario 1, 2, 3] [Refs: Problem Scenario 1, 2, 3]
10. There is no requirement that The Protocol publish a Practices of 8. There is no requirement that SSP publish a Practices of any/all
any/all third parties that MUST NOT sign on the domain holder's third parties that MUST NOT sign on the domain holder's behalf.
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 doesn't have to concern itself with being a protocol doesn't have to concern itself with being a
blacklist repository.] blacklist repository.]
[Refs: Problem Scenario 1-2] [Refs: Problem Scenario 1-2]
11. The Protocol MUST NOT be required to be invoked if a valid first 9. SSP MUST NOT be required to be invoked if a valid first party
party signature is found. signature is found.
[Refs: Deployment Scenario 2] [Refs: Deployment Scenario 2]
12. [PROVISIONAL] A domain holder MUST be able to publish a Practice 10. [PROVISIONAL] The signing policy statement MUST be capable of
which enumerates the acceptable cryptographic algorithms for fully describing a signing practice in which multiple signatures
signatures purportedly from that domain. are always provided such that the policy is of utility to any
verifier is capable of verifying any of the signatures that are
always provided. Such a mechanism MUST NOT:
* Require the verifier to perform any additional DNS lookups
* Require duplication of configuration data
* In particular not require the policy record to provide for
the description of any cryptographic or cannonicalization
algorithm
INFORMATIVE NOTE: The ability to specify multiple signatures
is necessary in order to permit orderly transitions to new
cryptographic and canonicalization algorithms. Unless the
policy language is not sufficiently expressive to allow the
signer to describe the actual signature practice in this case
there is an opportunity for an attacker to exploit the fact
that there are verifiers that do not yet support the new
algorithm.
[Refs: Deployment Scenario 7] [Refs: Deployment Scenario 7]
13. The protocol MUST NOT provide a mechanism which impugns the 11. SSP MUST NOT provide a mechanism which impugns the existence of
existence of non-first party signatures in a message. A non-first party signatures in a message. A corollary of this
corollary of this requirement is that the protocol MUST NOT link requirement is that the protocol MUST NOT link practices of
practices of first party signers with the practices of third first party signers with the practices of third party signers.
party signers.
[INFORMATIVE NOTE: the main thrust of this requirement is [INFORMATIVE NOTE: the main thrust of this requirement is
that practices should only be published for that which the that practices should only be published for that which the
publisher has control, and should not meddle in what is publisher has control, and should not meddle in what is
ultimately the local policy of the receiver.] ultimately the local policy of the receiver.]
[Refs: Deployment Scenario 3] [Refs: Deployment Scenario 3]
6.4. Extensibility and Forward Compatibility Requirements 5.4. Extensibility and Forward Compatibility Requirements
1. The Protocol MUST NOT extend to any other protocol than DKIM for 1. SSP MUST NOT extend to any other protocol than DKIM for email at
email at this time. The Protocol SHOULD be able to extend for this time. SSP SHOULD be able to extend for protocols other than
protocols other than DKIM. DKIM.
[Refs: Deployment Scenario 8] [Refs: Deployment Scenario 8]
2. The Protocol MUST be able to add new Practices and Expectations 2. SSP MUST be able to add new Practices and Expectations within the
within the existing discovery/transport/practices in a backward existing discovery/transport/practices in a backward compatible
compatible fashion. fashion.
[Refs: Deployment Scenario 8] [Refs: Deployment Scenario 8]
7. Security Requirements 6. Security Requirements
1. Minimize DoS potential: The Protocol for a high-value domain is 1. Minimize DoS potential: SSP for a high-value domain is
potentially a high-value DoS target, especially since the potentially a high-value DoS target, especially since the
unavailability of The Protocol's record could make unsigned unavailability of SSP's record could make unsigned messages less
messages less suspicious. suspicious.
2. Amplification Attacks: The Protocol MUST NOT make highly 2. Amplification Attacks: SSP MUST NOT make highly leveraged
leveraged amplification or make-work attacks possible. In amplification or make-work attacks possible. In particular any
particular any amplification must be O(1). amplification must be O(1).
[Author's question: is it really O(1)? or O(n)?] [Author's question: is it really O(1)? or O(n)?]
[Refs: Deployment Scenario 9] [Refs: Deployment Scenario 9]
3. Authenticity: The Protocol MUST have the ability for a domain 3. Authenticity: SSP MUST have the ability for a domain holder to
holder to provide The Protocol's data such that a receiver can provide SSP's data such that a receiver can determine that it is
determine that it is authentically from the domain holder with a authentically from the domain holder with a large degree of
large degree of certainty. The Protocol may provide means which certainty. SSP may provide means which provide less certainty in
provide less certainty in trade off for ease of deployment. trade off for ease of deployment.
[Refs: Deployment Scenario 9] [Refs: Deployment Scenario 9]
8. 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.
9. Security Considerations 8. Security Considerations
This draft defines requirements for a new protocol and the security This document defines requirements for a new protocol and the
related requirements are defined above. There is an expectation that security related requirements are defined above. There is an
The Protocol will not always be required to have source expectation that SSP will not always be required to have source
authentication of the practices information which is noteworthy. authentication of the practices information which is noteworthy.
10. Acknowledgments 9. Acknowledgments
Due to flipping in the market and raising interest rates, this home Due to flipping in the market and raising interest rates, this home
is no longer free. Dave Crocker and Jim Fenton helped me raise the is no longer free. Dave Crocker and Jim Fenton helped me raise the
walls on this draft and are accorded a room at the inn. The inn is walls on this document and are accorded a room at the inn. The inn
not yet full, however. is not yet full, however.
11. References 10. References
11.1. Normative References 10.1. Normative References
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM) Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-04 (work in progress), Signatures", draft-ietf-dkim-base-04 (work in progress),
July 2006. 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.
11.2. Informative References 10.2. Informative References
[I-D.ietf-dkim-overview] [I-D.ietf-dkim-overview]
Hansen, T., "DomainKeys Identified Mail (DKIM) Service Hansen, T., "DomainKeys Identified Mail (DKIM) Service
Overview", draft-ietf-dkim-overview-01 (work in progress), Overview", draft-ietf-dkim-overview-01 (work in progress),
June 2006. June 2006.
[I-D.ietf-dkim-threats] [I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006. in progress), May 2006.
skipping to change at page 26, line 7 skipping to change at page 24, line 7
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 Internet Society (2006). 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 94 change blocks. 
334 lines changed or deleted 309 lines changed or added

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