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

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

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 19, 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a
   cryptographic mechanism for domains to assert responsibility for the
   messages they sign. handle.  A related mechanism would allow an
   administrator to publish various statements about their email accountability DKIM signing
   practices.  This draft defines the requirement for this additional 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  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4  5

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

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

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

   5.  SSP Deployment Scenarios . . . .  7
     4.2.  Scenario 2: DKIM Signing Complete State . . . . . . . . .  8
     4.3. . . . . . . 11
     5.1.  Deployment Scenario 3: 1: Outsourced First Party Signing  . . . . . . . .  8
     4.4. 11
     5.2.  Deployment Scenario 4: 2: Determinism in Lookup Mechanism . . 11
     5.3.  Deployment Scenario 3: Resent Original Mail  . . . . . . . 11
     5.4.  Deployment Scenario 4: Incremental Deployment of
           Signing  . . . . . . . . .  9
     4.5. . . . . . . . . . . . . . . . . 12
     5.5.  Deployment Scenario 5: Incremental Transport Scenarios . . . . . . . . 12
     5.6.  Deployment Scenario 6: Human Legibility of Signing Practices . . . 13
     5.7.  Deployment Scenario 7: Cryptographic Downgrade Attacks . . 13
     5.8.  Deployment Scenario 8: Extensibility . . . .  9

   5.  Requirements . . . . . . . 13
     5.9.  Deployment Scenario 9: Security  . . . . . . . . . . . . . 13

   6.  Requirements . . . . . 11
     5.1.  Discovery Requirements . . . . . . . . . . . . . . . . . . 11
     5.2.  Transport requirements . . 15
     6.1.  Discovery Requirements . . . . . . . . . . . . . . . . 11
     5.3.  Practice and Expectation Requirements . . 15
     6.2.  Transport requirements . . . . . . . . 12
       5.3.1.  Negative Commentary . . . . . . . . . . 16
     6.3.  Practice and Expectation Requirements  . . . . . . . 12
     5.4. . . . 16
     6.4.  Extensibility and Forward Compatibilty Compatibility Requirements . . . 15

   6. 19

   7.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 16

   7. 20

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17

   8. 21

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18

   9.  Acknowledgements 22

   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19

   10. 23

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. 24
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. 24
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20 24

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 22 26

1.  Preface

   The purpose of this draft is get out into the open a range of issues
   related to the perceived need for a signing practices information
   service primarily focused on DKIM.  This document is intended to
   document well-agreed upon problems and requirements, in addition to
   less well-agreed upon requirements in an attempt 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, 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

   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: a Usage Problem and
   Deployment Scenario section which attempts to describe some common usage scenarios describes the problems that
   DKIM The
   Protocol is likely intended to be deployed in and address as well as the problems that are not solved
   by DKIM alone. deployment issues
   surrounding the base problems.  The second section is the
   Requirements that arise because of those usage scenarios, in addition to more basic protocol
   requirements. scenarios.

4.  Use  SSP Problem Scenarios

   The email world is a diverse world 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.  Problem Scenario 1: Bigbank.example.com

   There seems to be a class of mail -- mostly transactional All Mail Signed with DKIM

   After auditing their outgoing mail from
   high value domains -- that are the target and deploying DKIM signing for all
   of phishing attacks.  In
   particular, the phishing scams forge the [RFC2822].From address in
   addition their legitimate outgoing mail, a domain could be said to spoofing much of be DKIM
   signing complete.  That is, the content domain has to trick unsuspecting users
   into revealing sensitive information.  Domain holders sending this
   kind of mail would like the best of its ability to give better guarantees
   insured that
   mail sent in their name is with the consent of the domain holder.
   The first step is, of course, to use DKIM-base to sign all of the
   outgoing mail so that a receiver can make a determination that the
   mail is legitimately purporting to have come from the domain holder in question.

   The problem with this scenario is 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 those the
   practices and expectations of the sending domain when no valid
   signature is found could be useful to close the gap where an attacker merely sends
   unsigned mail to exploit a bid down attack.  It is assumed that
   receivers would 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 (ie with users and especially (eg where users are members of mailing lists)
   lists, etc) will likely suffer occasional damage 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 certain those usage patterns.  As such, this  This scenario defines a more limited situation where the risk of a legitimate piece of mail being mislabeled sender
   cannot set any expectation as
   unsigned outweights the risk of illegitimate mail being delivered in
   the eyes to whether an individual message will
   arrive intact.

   Even without that expectation, a receiver may be able to take
   advantage of the sender. 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 signature from A

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

4.2.  Scenario 2: DKIM Signing Complete State

   After auditing their outgoing mail and deploying DKIM signing for

   3.  A provides information that it signs all
   of their legitimate outgoing mail, a domain but
       places no expectation on whether it will arrive with an intact
       signature.

   4.  B could be said to be DKIM
   signing complete.  That is, the domain has use this information to the best of bias its ability
   insured filters such that all mail legitimately purporting it
       looks somewhat more suspicious.

4.2.  Problem Scenario 2: Illegitimate Domain Name Use

   There seems to have come be a class of mail -- mostly transactional mail from
   high value domains -- that
   domain contained a valid DKIM signature.  Given are the likelihood target of
   signature damage in the current mail infrastructure as noted above, a
   domain can fit phishing attacks.  In
   particular, many phishing scams forge the DKIM signing complete scenario without wanting [RFC2822].From address in
   addition to
   take the risks associated with the more narrow scope spoofing much of use in the
   previous scenario.  A receiver, on the other hand, may be able content to
   take advantage trick unsuspecting users
   into revealing sensitive information.  Domain holders sending this
   kind of mail would like the knowledge the domain's practice of signing all ability to give an enhanced guarantee
   that mail sent in order to use it to bias filters against their name should always arrive with the unexpected
   arrival provable
   consent of the domain holder.

   From a piece of unsigned or damaged in transit mail.

4.3.  Scenario 3: Outsourced First Party Signing

   Many domains do not run their own mail infrastructure, or may
   outsource parts of it to third parties.  It is desirable for receiver's standpoint, knowing that a domain
   holder to have the ability delegate to other entities the ability to
   sign for not only signs
   all of its mail, but also expects that legitimate mail from the
   domain holder will be received with either a first party valid signature or is quite interesting.
   This assertion from the
   equivalent.  One obvious use scenario signing domain is quite a domain holder for bit stronger than
   the assertion in Problem Scenario 1; even though a small
   domain that needs to have signer can never
   know the ability for their outgoing ISP to sign
   all of their true path mail on behalf of will take before delivery, 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.

   That said, DKIM uses DNS to store selectors.  Thus there implication is always
   that if the ability for message is lacking a domain holder to delegate all valid signature the message is
   either malicious or parts of is the
   _domainkey subdomain to a third party responsibility of the signing domain holder's
   choosing.  That is, to
   avoid whatever broke the domain holder signature.

      [Informative Note: in terms of a receiving filter, one may be able choose
      to set a NS record
   for _domainkey.example.com to, say, an email provider who manages
   that namespace.  There treat scenario 2 much more harshly than scenario 1; where
      scenario 1 looks odd, scenario 2 looks like something is also the ability for the domain holder to
   partition its namespace into subdomains very
      wrong]

   1.  Mail with a [RFC2822].From A purportedly sends to further constrain how
   third parties.  For example, B with a domain holder
       missing or broken 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
       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.  SSP Deployment Scenarios

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

5.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.  Deployment Scenario 2: Determinism in Lookup Mechanism

   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
   _domainkey.benefits.example.com 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 be bound to some small finite number of queries.

5.3.  Deployment Scenario 3: Resent Original Mail

   Resent mail is a third party to constrain common occurrence in many scenarios in the
   third party 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 only be able to produce valid signatures take his part of
   the responsibility of the message in question, so he DKIM signs the
   benefits.example.com subdomain.

   There have been concerns expressed about how well this would scale
   when
   message, perhaps corresponding to the third party is, say, a large ISP Sender address.

   Note that signs 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 thousands the benefit of
   domains.  There has been concern about how well this the ultimate
   receivers.  It would work be useful for
   multiple delegations.  Another concern is 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 all DNS providers
   give the ability friendly to specify delegations.  Lastly, using NS
   delegations requires that DKIM
   first party signatures (ie, break them) can be potentially assessed
   by the signer actively cooperate with receiver based on the
   domain for whom it is signing.  That is, receiver's opinion of the signing
   domains that actually survived.

5.4.  Deployment Scenario 4: Incremental Deployment of Signing

   As a practical matter, it requires may be difficult for a domain to roll out
   DKIM signing such that they can publish the signer
   actively manage 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 _domainkey delegation for least common denominator of the domain holder.  A
   domain holder published practices.  It would not, for example, be able
   desirable to make allow a statement
   that ISP.com signing on its behalf was acceptable without ISP.com's
   cooperation.  This by extension also applies domain holder to other third parties
   that publish a domain list of exceptions
   which would have a stronger practices statement.

   For example, bigbank.example.com might like be ready to effectively "whitelist" such as mailing
   lists say that re-sign mail
   statements@bigbank.example.com is always signed, but the rest of the
   domain, say, is not.  Another situation is that the domain holder holds practices of some
   address local parts in esteem.

4.4.  Scenario 4: Resent Original Mail

   Resent mail is a common occurrence in many scenarios in given domain are not the email
   world same as practices
   of today.  For example, Alice sends a DKIM signed message with other local parts.  Using the same example of
   statements@bigbank.example.com being a published practice transactional kind of signing all messages sent from Alice's domain email
   which would like to Bob's mailing list publish very strong practices, mixed in another domain.  Bob, being with the
   rest of the user population local parts which may go through mailing
   lists, etc, for which a good net
   citizen, wants to less strong statement is appropriate.

   It should be able said that DKIM, through the use of subdomains, can
   already support this kind of differentiation.  That is, in order to take his part
   publish a strong practice, one only has to segregate those cases into
   different subdomains.  For example: *@accounts.bigbank.example.com
   would publish a strong practice while *@bigbank.example.com could
   publish a more permissive practice.

5.5.  Deployment Scenario 5: Transport Scenarios

   Email service provides an any-any mesh of potential connections: all
   that is required is the responsibility publication of an MX record and a SMTP
   listener to receive mail.  Thus the message in question, so he DKIM signs the message.

   Note that this scenario use of The Protocol is completely orthogonal to whether Alice's
   signature survived Bob's mailing list: Bob merely wants likely to assert his
   part in
   fall into two main scenarios, the chain first of accountability 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 benefit
   caching of the ultimate
   receivers.  It would be useful for this practice to 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 encouraged both perfectly normal as
   it gives a more accurate view of who handled the message, and
   with the
   trustworthiness case of vanity domains, and sadly a vector for those sending
   mail for anti-social reasons.  In this case we'd like the handlers.  It also has the side benefit that
   remailers that are not friendly burden to
   The Protocol querier to DKIM first party signatures (ie,
   break them) can still be potentially assessed by the receiver based
   on the receiver's opinion low, since many of the signing domains that actually
   survived.

4.5.  Scenario 5: Incremental Deployment of Signing

   As lookups will not
   provide a practical matter, useful answer.  Likewise, it may would be difficult for advantageous to have
   upstream caching here as well so that, say, a mailing list exploder
   on a small domain to roll out
   DKIM signing such that they can publish the DKIM Signing Complete
   practice for its given the complexities does not result in an explosion of queries back at
   the user population,
   outsourced vendors sending on its behalf, etc.  This leaves open an
   exploit that high-value mail must be classified to root server for the least common
   denominator small domain.

5.6.  Deployment Scenario 6: Human Legibility of Practices

   While The Protocol records are likely to be primarily consumed by an
   automaton, for the published practices. foreseeable future they are also likely to be
   inspected by hand.  It would be desirable to
   allow a domain holder nice to publish a list of exceptions which would have a stronger practices statement.

   In this situation, 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 stated in
   a given domain fashion which is also intuitive to the human inspectors.

      [Author's $.02: it's been amply demonstrated that simple human
      readable labels are not often misconstrued.  Opaque symbols do have
      the same as practices
   of other local parts.  Using advantage that you need to consult the same example of
   statements@bigbank.example.com being a transactional kind of email
   which would like definition to publish very strong practices, mixed in 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
   with the
   rest of the user population local parts which may go through mailing
   lists, etc, for which a less strong statement previously acceptable but now insecure hash algorithm.  This
   could allow attackers to send their chosen text which is appropriate. apparently
   signed by the targeted domain.  It
   should would be said that DKIM, through the use of subdomains, can already
   support this kind of differentiation.  That is, in order advantageous for a domain
   to publish a
   strong practice, one what the allowable signing/hashing algorithms are to
   prevent this downgrade attack.

5.8.  Deployment Scenario 8: Extensibility

   While this document pertains only has to segregate those cases into different
   subdomains.  For example: *@accounts.bigbank.example.com requirements surrounding DKIM
   signing practices, it would
   publish be beneficial for the protocol to be able
   to extend to other protocols.

5.9.  Deployment Scenario 9: Security

   The protocol 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 practice while *@bigbank.example.com could publish source authentication provided by the information
   service, a
   more permissive practice.

5. path to strong source authentication should be provided by
   the protocol, or underlying protocols.

6.  Requirements

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

5.1.  Discovery Requirements

   1.  Discovery mechanism MUST be rooted in DNS.

   2.  Discovery mechanism MUST converge in a deterministic number of
       exchanges.

          [Informative Note: this, for all intents and purposes is a
          prohibition on anything that might produce loops; also though
          "deterministic" doesn't specify how many exchanges, the
          expectation is "few".]

   3.  Discovery mechanism MUST NOT overload semantics of existing DNS
       resource records where name space collisions are plausible.  For
       the purposes of this requirement, neither an underscore prefixed
       namespace nor a new resource record type are considered
       plausible.

5.2.  Transport requirements

   1.  Widespread deployment of the transport layer would be highly
       desirable, especially if riding on top of a true transport layer
       (eg, TCP, UDP).

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

   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.

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

5.3.  Practice and Expectation Requirements

   In this section, a Practice is defined as a true statement according
   to the [RFC2822].From domain holder of its intended externally
   viewable behavior.  An Expectation combines with a Practice to convey
   what the domain holder considers be true, the likely outcome of provisional requirement should
      either be dropped or the
   survivability harder requirements revised]

6.1.  Discovery Requirements

   Receivers need a means of the Practice at obtaining information about a receiver.  For example, sender's DKIM
   practices.  This requires a Practice
   that X is true when it leaves means of discovering where the domain,
   information is and an Expectation that what it
   will|will-not|may|may-not remain true for some/all receivers. contains.

   1.  The Protocol MUST be able to make Practices and Expectation
        assertions about author is the [RFC2822].From address first-party sender of a message, as specified
       in the context of
        DKIM. [rfc2822].From field.  The Protocol will not make assertions about other
        addresses for DKIM at this time.

   2.   The Protocol MUST be able to publish a Practice that Protocol's information is
       associated with the author's domain
        doesn't send mail.

   3.   The Protocol MUST be able name and is published
       subordinate to publish a Practice that domain name.

   2.  In order to limit the
        domain's signing behavior is "DKIM Signing Complete"

   4. cost of its use, any query service
       supplying The Protocol MUST be able to publish an Expectation that Protocol's information must provide a
        verifiable First Party DKIM Signature should be expected on
        receipt of definitive
       responsive within a message. small, deterministic number of query
       exchanges.

          [Informative Note: the DKIM Signing Complete Practice seems
           to be a pre-requisite for this Expectation]

   5.   [PROVISIONAL] A domain MUST be able to delegate responsibility this, for signing its messages to a non-related domain in such all intents and purposes is a way
          prohibition on anything that it does not require active participation by the non-related
        domain.  That is, might produce loops or result in
          extended delays and overhead; also though "deterministic"
          doesn't specify how many exchanges, the published information expectation is "few".]

          [Refs: Deployment Scenario 2]

   3.  The Protocol's publishing mechanism MUST have a way be defined to
        specify the domains that are allowed produce
       unambiguous semantics, particularly with respect to sign on its behalf.

     5.3.1.  Negative Commentary

        1.  Scaling Concerns for DNS: the addition of third party
            signers begs the question of how that other
       information is stored
            in the DNS if that is might share the repository (which seems pretty
            likely).  The naive approach publication mechanism.

          [Informative note: An example of just encoding them into one ambiguity is sharing resource
          record could quite plausiblely exceed the maximum types within a common DNS UDP MTU which leaf.  Hence, uniquely
          defined leaf names or uniquely defined resource record types
          will ensure unambiguous reference.]

          [Refs: Deployment Scenario 2]

6.2.  Transport requirements

   1.  Widespread deployment of the transport layer would be highly undesirable.  Other
            approaches have been suggested, but they seemingly trade off
            complexity, number
       desirable, especially if riding on top of lookups, non-deterministic completion,
            etc. a true transport layer
       (eg, TCP, UDP).

          [Refs: Deployment Scenario 5, 8]

   2.  Alternate mechanism to NS delegation,  A low-cost query/response in terms of latency time and threats not well
            understood: the mechanism for delegating zones within DNS is
            a very well understood problem which well understood
            threats.  The threats involved with another form number
       of
            indirection are far less clear, though undoubtably present.
            There packets involved is a great deal of concern that (re)discovering those
            threats, deciding whether they are valid, whether they 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 mitigated, etc, etc are a worthwhile exercise given that
            this provides minimal functionality over what currently
            exists with DKIM base.

        3.  The seems 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 a strong consensus
       supported for most of requirements, high availability

          [Refs: Deployment Scenario 5, 8]

6.3.  Practice and quite Expectation Requirements

   In this section, a bit less for this, Practice is there harm if we don't do
            this now?  That is, can it extended later if needed based on
            much more experience?

        4.  Concerns about conflation of responsibility and/or
            reputation: there are concerns defined as a true statement according
   to the [RFC2822].From domain holder of adding its intended externally
   visible behavior.  An Expectation combines with a Practice to convey
   what the confusion
            about who is taking responsibility for what.  Is it the d= domain in holder considers the DKIM-signature?  Is it likely outcome of the domain in
   survivability of the From:
            address?  Is it both?  Is Practice for a receiver.  For example, a
   Practice that X is true when it neither?  Keeping this simple
            by using leaves the NS delegation mechanism would not raise these
            interesting, if not thorny questions.

        5.  It's not clear domain, and an Expectation
   that this requirement actually delivers on it will|will-not|may|may-not remain true for some/all receivers.

   1.   The Protocol MUST be able to make Practices and Expectation
        assertions about the less complexity aspect of its billing: one of [RFC2822].From address in the
            attractions context of
        DKIM.  The Protocol will not make assertions about other
        addresses for DKIM at this requirement time.

           [Refs: Problem Scenario 1,2]

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

           [Refs: Problem Scenario 3]
   3.   If the Discovery process would be
            little 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 no interaction required between "I sign some mail" practice is useless to
           receivers.  However, a null practice may help to cut short
           the first party policy lookup mechanism if it's published, and if that's
           the designated third party signer.  Given the security
            issues with this approach, case it is not clear that the
            interaction required between seems worthwhile.  Also, a null policy may have
           some forensic utility, such as gaging the first and third parties are
            any less onerous.

        6.  Security Threat with number of domains
           considering/using DKIM base, a first party signer can
            always clarify which address it is for example.]

           [Refs: Deployment Scenario 2]

   4.   The Protocol MUST be able to publish a Practice that the
        domain's signing behavior is "DKIM Signing Complete"

           [Refs: Problem Scenario 1]

   5.   The Protocol MUST be able to publish an Expectation that a
        verifiable First Party DKIM Signature should be expected on behalf
        receipt of by
            using the i= tag.  That is, when there's ambiguity between,
            say, From: a message.

           [Refs: Problem Scenario 2]

   6.   Practices and Sender: the signer has Expectations MUST be presented in the ability Protocol
        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 clarify
            which address the signature was sign on behalf of if it so
            desires.  For a third party signature, domain's behalf.  Because DKIM
        uses DNS to store selectors, there is no clarity
            since the signature by definition has no relationship to always the
            origination addresses.

               A legitimate flow follows:

               -  An ISP signs ability for both a.com and mailinglist.com

               -  mailinglist.com sends a piece of mail From:
                  president@a.com, Sender: list@mailinglist.com
               -  ISP signs the message with d=ISP.com

               -  The receiver at this point has no idea who ISP.com was
                  signing on behalf
        domain holder to delegate all or parts of because they are both
                  legitimately signed by ISP.com

            The attack is essentially identical: it only requires that
            mailinglist.com spoof the From: address _domainkey
        subdomain to whatever other
            customer an affiliated party of ISP.com. the domain holder's
        choosing.  That is, mailinglist.com can the domain holder may be any
            example.com with bad intentions.  Worse, is able to set a NS
        record for _domainkey.example.com to, say, an email provider who
        manages that namespace.  There is also the ISP
            will ordinarily have no clue as ability for the
        domain holder to whether partition its customers are
            running mailing lists or not, so it would not have 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
            ability "legitimate" From: spoofing (ie, benefits.example.com subdomain.
        Last, a real mailing
            list) from illegitimate spoofing.

   6. domain holder can even use CNAME's to delegate
        individual leaf nodes.

   8.   [PROVISIONAL] The protocol MUST have the ability to provide
        practices and expecations 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]

   7.

           [Refs: Deployment Scenario 4]

   9.   Practices and Expectations MUST be presented as an information
        service from the sender 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.

   8.   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
           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.]

   9.

           [Refs: Problem Scenario 1, 2, 3]

   10.  There is no requirement that The Protocol 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.]

   10.

           [Refs: Problem Scenario 1-2]

   11.  The Protocol MUST NOT be required to be invoked if a valid first
        party signature is found.

   11.

           [Refs: Deployment Scenario 2]

   12.  [PROVISIONAL] A domain holder MUST be able to publish a Practice
        which enumerates the acceptable cryptographic algorithms for
        signatures purportedly from that domain.

           [INFORMATIVE NOTE: this is to counter a bid down attack; some
           comments indicated that this need only be done if the
           algorithm was considered suspect by the receiver; I'm not
           sure that I've captured that nuance correctly]

   12.  Given the considerations in scenario 4, the

           [Refs: Deployment Scenario 7]

   13.  The protocol MUST NOT provide a mechanism which impugns the mere
        existence of third non-first party signatures in a message.  A corrolary
        corollary of this requirement is that the protocol MUST NOT in any way tie 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 restate meddle in what is
           ultimately the local policy of the receiver.]

5.4.

           [Refs: Deployment Scenario 3]

6.4.  Extensibility and Forward Compatibilty Compatibility Requirements

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

          [Refs: Deployment Scenario 8]

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

   3.  [PROVISIONAL] The Protocol MUST be able to extend for new
       protocols signed by DKIM

   4.  [PROVISIONAL] The Protocol MUST be able to extend for protocols
       other than DKIM

6.

          [Refs: Deployment Scenario 8]

7.  Security Requirements

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

   2.  Amplification Attacks: The Protocol 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 MUST have the ability for a domain
       holder to provide The Protocol's data such that a receiver can
       determine that it is authentically from the domain holder with a
       large degree of certainty.  The Protocol may provide means which
       provide less certainty in trade off for ease of deployment.

7.

          [Refs: Deployment Scenario 9]

8.  IANA Considerations

   This document makes no request of IANA.

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

8.

9.  Security Considerations

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

9.  Acknowledgements

   still free

10.  Acknowledgments

   Due to good flipping in the market and raising interest rates, this home

10.
   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
   not yet full, however.

11.  References

10.1.

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

10.2.

11.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).

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