doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

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