DKIM Working Group                                             M. Thomas
Internet-Draft                                             Cisco Systems
Intended status: Informational                            September 2006
Expires:                             March 5, 6, 2007
Expires: September 7, 2007

           Requirements for a DKIM Signing Practices Protocol
                  draft-ietf-dkim-ssp-requirements-02
                  draft-ietf-dkim-ssp-requirements-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 5, September 7, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] (DKIM) provides a cryptographic mechanism
   for domains to assert responsibility for the messages they handle.  A
   related mechanism would will allow an administrator to publish various
   statements about their DKIM signing practices.  This draft document defines the requirement
   requirements for this mechanism.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Preface  . .  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  SSP Problem Scenarios  . . . . . . . . . . . . . . . . . . . .  8
     4.1.  7
     3.1.  Problem Scenario 1: All Mail Signed with DKIM  . . . . . .  8
     4.2.  7
     3.2.  Problem Scenario 2: Illegitimate Domain Name Use . . . . .  9
     4.3.  Problem Scenario 3: Domain Sends No Mail . . . . . . . . . 10

   5.  8

   4.  SSP Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
     5.1. 10
     4.1.  Deployment Scenario 1: Outsourced Signing  . . . . . . . . 11
     5.2. 10
     4.2.  Deployment Scenario 2: Determinism in Lookup Mechanism
           and Subdomain Coverage . . 11
     5.3. . . . . . . . . . . . . . . . . 10
     4.3.  Deployment Scenario 3: Resent Original Mail  . . . . . . . 11
     5.4. 10
     4.4.  Deployment Scenario 4: Incremental Deployment of
           Signing  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.5. 11
     4.5.  Deployment Scenario 5: Transport Scenarios . . . . . . . . 12
     5.6. 11
     4.6.  Deployment Scenario 6: Human Legibility of Practices . . . 13
     5.7. 12
     4.7.  Deployment Scenario 7: Cryptographic Downgrade Attacks . . 13
     5.8. 12
     4.8.  Deployment Scenario 8: Extensibility . . . . . . . . . . . 13
     5.9. 12
     4.9.  Deployment Scenario 9: Security  . . . . . . . . . . . . . 13

   6. 12

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1. 13
     5.1.  Discovery Requirements . . . . . . . . . . . . . . . . . . 15
     6.2. 13
     5.2.  SSP Transport requirements . . Requirements . . . . . . . . . . . . . . . . 16
     6.3. 14
     5.3.  Practice and Expectation Requirements  . . . . . . . . . . 16
     6.4. 14
     5.4.  Extensibility and Forward Compatibility Requirements . . . 19

   7. 17

   6.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 20

   8. 18

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21

   9. 19

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22

   10. 20

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23

   11. 21

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1. 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2. 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 24 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 26 24

1.  Preface

   The purpose of this draft is get out into the open  Introduction

   DomainKeys Identified Mail [I-D.ietf-dkim-base]defines a range of issues
   related to the perceived need message
   level signing and verification mechanism for email.  While a signing practices information
   service primarily focused on DKIM.  This document DKIM
   signed message speaks for itself, there is intended to
   document well-agreed upon problems and requirements, in addition to
   less well-agreed upon requirements in an attempt ambiguity if a message
   doesn't have a valid first party signature: is this to capture the issue
   as well as generalize the requirement as much as possible.  These
   latter requirements will be noted as "[PROVISIONAL]" to indicate that
   there is not yet solid consensus, expected or that the
   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 well
   understood.  A winnowing process
   assume that the lack of a valid signature is envisioned where a priori invalid.  Thus,
   an attacker can take advantage of the more
   difficult and/or speculative problems/requirement will ambiguity and simply not sign
   messages.  If a protocol could be eliminated
   unless concrete 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.

   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: a Problem and Deployment Scenario
   section which describes the problems with proven constituencies can be
   demonstrated, along with reasonable plausibility that they do not
   contradict more SSP is intended to address
   as well agreed upon requirements. as the deployment issues surrounding the base problems.  The
   second section is the Requirements that arise because of those
   scenarios.

2.  Definitions

   o  Domain Holder: the entity that ultimately 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 domain tag (d= or the more specific identity
      i= tag) matches the first party address.  "Matches" in this
      context is defined in [I-D.ietf-dkim-base]

   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 does is not required to
      correspond to 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
   base signing mechanism for email.  This work is contained in
   [I-D.ietf-dkim-base].  In addition there are two other documents
   [I-D.ietf-dkim-overview] and [I-D.ietf-dkim-threats] which give an
   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
   verifying DKIM signatures, there has been a great deal of interest in
   a signing practices protocol.  The most pressing case seems to be the
   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: valid
      signature that does not qualify as a Problem and
   Deployment Scenario section which describes the problems First Party Signature.  Note
      that The
   Protocol a DKIM third party signature is intended not required to correspond to
      a third party address such as well as Sender or Listid, etc.

   o  Practice: a statement according to the deployment issues
   surrounding [RFC2822].From domain
      holder of externally verifiable behavior in the base problems.  The second section is email messages it
      sends.  A practice should always be true when received by a
      topologically adjacent SMTP.

   o  Expectation: an Expectation combines with a Practice to convey
      what the
   Requirements that arise because domain holder considers the likely survivability of those scenarios.

4. the
      Practice for a non-topologically adjacent receiver.

   o  DKIM Signing Complete: a Practice where the domain holder asserts
      that all legitimate mail will be sent with a valid First Party
      Signature.

3.  SSP Problem Scenarios

   The email world is a diverse place with many deployment scenarios.
   This section tries to outline some usage scenarios that it is
   expected that DKIM signing/verifying will take place in, and how a
   new protocol might be helpful to clarify the relevance of DKIM signed
   mail.

4.1.

3.1.  Problem Scenario 1: 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
   insured that all mail legitimately 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, or what their expectations are for unsigned mail.
   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
   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 which allowed a receiver to query for the
   practices and expectations of the sending 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, DKIM signature breakage for unrestricted use patterns of
   mail (eg where users are 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, the kind (quality) 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 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.

   1.  Mail with a [RFC2822].From A purportedly sends to B with a
       missing or broken DKIM first party signature from A

   2.  B would like to know whether that is an expected state of
       affairs.

   3.  A provides information that it signs all outgoing mail, but
       places no expectation on whether it will arrive with an intact
       first party signature.

   4.  B could use this information to bias its filters such that it
       looks somewhat more suspicious.

4.2.

3.2.  Problem Scenario 2: Illegitimate Domain Name Use

   There seems to be a

   A class of mail -- mostly typified by transactional mail from high value
   domains -- that are is 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 kind of
   mail would like the ability to give an enhanced guarantee that mail
   sent in their name should always arrive with the provable
   consent of proof that the
   domain holder. 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 also expects that legitimate mail from places a very high value on the
   domain will be received with receipt of a
   valid first party signature is quite interesting.
   This assertion from the signing that domain is quite a bit stronger than
   the assertion in Problem Scenario 1; even though helpful.  Hence a signer
   receiver can never know the true path mail will take before delivery, the implication is that if the message is lacking a valid signature the message is
   either malicious or is domain not only signs all of its mail, but
   also feels it essential that legitimate mail must have its first
   party signatures survive transit.  A receiver with the responsibility knowledge of
   the signing domain sender's expectations in hand might choose to process messages
   not conforming to
   avoid whatever broke the signature. published practices in a special manner.

      [Informative Note: in terms of a receiving filter, one 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]

   1.  Mail with a [RFC2822].From A purportedly sends to B with a
       missing or broken first party DKIM signature from A

   2.  B would like to know whether that is an expected state of
       affairs.

   3.  A provides information that it signs all outgoing mail, but
       places an expectation that it should arrive with an intact first
       party signature, and that the receiver should be suspicious if it
       does not.

   4.  B could use this information to bias its filters such that it
       looks much more suspicious.

4.3.  Problem Scenario 3: Domain Sends No Mail

   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.

4.  SSP Deployment Scenarios

   Given the problems enumerated above for which we'd like The Protocol 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 The Protocol SSP would provide.

5.1.

4.1.  Deployment Scenario 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 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.

5.2.

4.2.  Deployment Scenario 2: Determinism in Lookup Mechanism

   The Protocol's and
      Subdomain Coverage

   SSP'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  The
   RFC2822.From address
   would will be used as a basis for the lookup.  In particular,  More
   precisely the domain part of the first address would be consulted in some manner of the RFC2822.From
   will form the trust basis to fetch the published information.  There is a fairly  A
   trivial attack against to circumvent finding the published information could
   be mounted by simply using a
   naive use subdomain of this algorithm 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 The Protocol's information service

   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 draft was that the number of
   lookups, on average should be small, and that the discovery process
   should always covered by SSP's information service.  Thus, it would
   be bound advantageous for The Protocol to some small finite number not only cover a given domain,
   but all subdomains of queries.

5.3. that domain as well.

4.3.  Deployment Scenario 3: Resent Original Mail

   Resent mail is a common occurrence in many scenarios in the email
   world of today.  For example, Alice sends a DKIM signed message with
   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
   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 are not friendly to DKIM
   first party signatures (ie, break them) can be potentially assessed
   by the receiver based on the receiver's opinion of the signing
   domains that actually survived.

5.4.

4.4.  Deployment Scenario 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, 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
   which would have a stronger practices statement.

   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
   which 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.

   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 accounts.bigbank.example.com
   would publish a strong practice constrained practices while *@bigbank.example.com could
   corporateusers.bigbank.example.com might publish a more permissive practice.

5.5.
   practices.

4.5.  Deployment Scenario 5: Transport Scenarios

   Email service provides an any-any mesh of potential connections: all
   that is required is the publication of an MX record and a SMTP
   listener to receive mail.  Thus the use of The Protocol SSP is likely to fall into
   two main scenarios, the first of which are large, well known domains
   who 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 (ie, 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 sadly a vector for those sending
   mail for anti-social reasons.  In this case we'd like the burden to
   The Protocol
   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
   server for the small domain.

5.6.

4.6.  Deployment Scenario 6: Human Legibility of Practices

   While The Protocol 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 which is also intuitive to the human inspectors.

      [Author's $.02: it's been amply demonstrated that simple human
      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.

4.7.  Deployment Scenario 7: Cryptographic Downgrade Attacks

   There is a downgrade attack possible where when a DKIM signature is hashed
   with a previously acceptable but now insecure hash algorithm.  This
   could allow attackers to send their chosen text which is apparently
   signed by the targeted domain.  It would be advantageous for a domain
   to publish what the allowable signing/hashing algorithms are to
   prevent this downgrade attack.

5.8.

4.8.  Deployment Scenario 8: 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.

5.9.

4.9.  Deployment Scenario 9: Security

   The protocol

   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
   strong source authentication provided by the information service, a
   path to strong source authentication should be provided by the
   protocol, or underlying protocols.

6.

5.  Requirements

   This section defines the requirements for The Protocol. SSP.  As with most
   requirements drafts, documents, these requirements define the MINIMUM
   requirements that a candidate protocol must provide.  It should also
   be noted that The Protocol 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.

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.  The Protocol's  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 The Protocol's SSP's information must MUST provide a definitive responsive
       within a small, deterministic number of query exchanges.

          [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 Scenario 2]

   3.  The Protocol's  SSP's publishing mechanism MUST be defined to produce
       unambiguous semantics, particularly with respect to other
       information such that might share it does not
       lead to multiple records of different protocols residing at the publication mechanism.
       same location.

          [Informative note: An example of ambiguity is sharing multiple resource record types of
          the same type within a common DNS leaf.  Hence, uniquely
          defined leaf names or uniquely defined resource record types
          will ensure unambiguous reference.]

          [Refs: Deployment Scenario 2]

6.2. 2]

   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 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
       desirable, especially if riding on top of a true transport layer
       (eg, TCP, UDP).

          [Refs: Deployment Scenario 5, 8]

   2.  A low-cost query/response in terms of latency time and the number
       of packets involved is highly desirable.

          [Refs: Deployment Scenario 5]

   3.  If the infrastructure doesn't provide caching (ala DNS), the
       records retrieved will need time-to-live values to allow querying
       verifiers to maintain their own caches.  Existing caching
       infrastructure is, however, highly desirable.

          [Refs: Deployment Scenario 5]

   4.  Multiple geographically and topologically diverse servers must be
       supported for high availability

          [Refs: Deployment Scenario 5, 8]

6.3.

5.3.  Practice and Expectation Requirements

   In this section,

   As stated in the definitions a Practice is defined as a true statement according to
   the [RFC2822].From domain holder of its intended externally
   visible behavior.  An verifiable behavior in
   the email messages it sends.  As a silly example, a Practice might be
   defined that all email messages will contain an X-Silly header.
   Since there is a possibility of alteration between what a sender
   sends and a receiver examines, an Expectation combines with a
   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 X-Silly is true present when it leaves is sent from the
   domain, and an Expectation that it will|will-not|may|may-not will remain true present for some/all receivers. receivers
   whether topologically adjacent or not.

   1.   The Protocol   SSP MUST be able to make Practices and Expectation assertions
        about the [RFC2822].From address in the context of DKIM.  The Protocol  SSP
        will not make assertions about other addresses for DKIM at this
        time.

           [Refs: Problem Scenario 1,2]

   2.   [PROVISIONAL] The Protocol   SSP MUST be able to publish a Practice
        which is indicative that domain doesn't send mail.

           [Refs: Problem Scenario 3]
   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 concise linkage between the policy lookup mechanism if it's published, [RFC2822].From
        and if that's the case identity in the DKIM i= tag, or its default if it seems worthwhile.  Also, a null policy may have
           some forensic utility, such as gaging is
        missing in the number signature.  That is, SSP MUST precisely define
        the semantics of domains
           considering/using DKIM for example.] what qualifies as a First Party Signature.

           [Refs: Deployment Problem Scenario 2]

   4.   The Protocol 1,2]

   3.   SSP MUST be able to publish a Practice that the domain's signing
        behavior is "DKIM Signing Complete" Complete".  That is, all messages were
        transmitted with a valid first party signature.

           [Refs: Problem Scenario 1]

   5.   The Protocol

   4.   SSP MUST be able to publish an Expectation that a verifiable First Party
        first party DKIM Signature should be expected on receipt of a
        message.

           [Refs: Problem Scenario 2]

   6.

   5.   Practices and Expectations MUST be presented in the Protocol SSP syntax using
        as intuitive a descriptor as possible.  For example, p=? would
        be better represented as p=unknown.

           [Refs: Deployment Scenario 6]

   7.   The Protocol MUST NOT invent a different means of allowing
        affiliated parties to sign on a domain's behalf. as p=unknown.

           [Refs: Deployment Scenario 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 be able to
        set a NS record for _domainkey.example.com to, say, an email
        provider who manages that namespace.  There is also the ability
        for the 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
        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.

   8.   [PROVISIONAL] The protocol MUST have the ability to provide
        practices and expectations keyed off of the local part of the
        [RFC2822].From address.  As with all provisional requirements,
        this requirement must  Thus SSP need not be in conflict with other
        requirements, including DNS considerations, etc.

           [INFORMATIVE NOTE: this requirement seems invent a different
        means of allowing affiliated parties to have rather weak
           support.  It's mainly been added so that it can be issue-
           tracked. /mat]

           [Refs: Deployment Scenario 4]

   9. sign on a domain's
        behalf at this time.

   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 Scenario 1, 2, 3]

   10.

   8.   There is no requirement that The Protocol SSP publish a 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 Scenario 1-2]

   11.  The Protocol

   9.   SSP MUST NOT be required to be invoked if a valid first party
        signature is found.

           [Refs: Deployment Scenario 2]

   12.

   10.  [PROVISIONAL] A domain holder The signing policy statement MUST be able to publish capable of
        fully describing a Practice signing practice in which enumerates multiple signatures
        are always provided such that the acceptable cryptographic algorithms 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 purportedly from
           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 domain. there are verifiers that do not yet support the new
           algorithm.

           [Refs: Deployment Scenario 7]

   13.  The protocol

   11.  SSP MUST NOT provide a mechanism which 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 Scenario 3]

6.4.

5.4.  Extensibility and Forward Compatibility Requirements

   1.  The Protocol  SSP MUST NOT extend to any other protocol than DKIM for email at
       this time.  The Protocol  SSP SHOULD be able to extend for protocols other than
       DKIM.

          [Refs: Deployment Scenario 8]

   2.  The Protocol  SSP MUST be able to add new Practices and Expectations within the
       existing discovery/transport/practices in a backward compatible
       fashion.

          [Refs: Deployment Scenario 8]

7.

6.  Security Requirements

   1.  Minimize DoS potential: The Protocol SSP for a high-value domain is
       potentially a high-value DoS target, especially since the
       unavailability of The Protocol's SSP's record could make unsigned messages less
       suspicious.

   2.  Amplification Attacks: The Protocol SSP MUST NOT make highly leveraged
       amplification or make-work attacks possible.  In particular any
       amplification must be O(1).

          [Author's question: is it really O(1)? or O(n)?]

          [Refs: Deployment Scenario 9]

   3.  Authenticity: The Protocol SSP MUST have the ability for a domain holder to
       provide The Protocol's SSP's data such that a receiver can determine that it is
       authentically from the domain holder with a large degree of
       certainty.  The Protocol  SSP may provide means which provide less certainty in
       trade off for ease of deployment.

          [Refs: Deployment Scenario 9]

8.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

9.

8.  Security Considerations

   This draft document defines requirements for a new protocol and the
   security related requirements are defined above.  There is an
   expectation that
   The Protocol SSP will not always be required to have source
   authentication of the practices information which is noteworthy.

10.

9.  Acknowledgments

   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
   walls on this draft document and are accorded a room at the inn.  The inn
   is not yet full, however.

11.

10.  References

11.1.

10.1.  Normative References

   [I-D.ietf-dkim-base]
              Allman, E., "DomainKeys Identified Mail (DKIM)
              Signatures", draft-ietf-dkim-base-04 (work in progress),
              July 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

11.2.

10.2.  Informative References

   [I-D.ietf-dkim-overview]
              Hansen, T., "DomainKeys Identified Mail (DKIM) Service
              Overview", draft-ietf-dkim-overview-01 (work in progress),
              June 2006.

   [I-D.ietf-dkim-threats]
              Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
              in progress), May 2006.

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

Full Copyright Statement

   Copyright (C) The Internet Society (2006). 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 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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).