[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 5016

DKIM Working Group                                             M. Thomas
Internet-Draft                                             Cisco Systems
Intended status: Informational                           August 10, 2006
Expires: February 11, 2007


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

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 February 11, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).














Thomas                  Expires February 11, 2007               [Page 1]


Internet-Draft                DKIM-SSP-REQ                   August 2006


Abstract

   DomainKeys Identified Mail [DKIM] provides a cryptographic mechanism
   for domains to assert responsibility for the messages they sign.  A
   related mechanism would allow an administrator ot publish various
   statements about their email accountability practices.  This draft
   defines the requirement for this additional mechanism.


Table of Contents

   1.  Preface  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   4.  Use Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Scenario 1: Bigbank.example.com  . . . . . . . . . . . . .  6
     4.2.  Scenario 2: DKIM Signing Complete  . . . . . . . . . . . .  7
     4.3.  Scenario 3: Outsourced First Party Signing . . . . . . . .  7

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Discovery Requirements . . . . . . . . . . . . . . . . . .  9
     5.2.  Transport requirements . . . . . . . . . . . . . . . . . .  9
     5.3.  Practice and Expectation Requirements  . . . . . . . . . . 10
     5.4.  Extensibility and Forward Compatibilty Requirements  . . . 11

   6.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 12

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18









Thomas                  Expires February 11, 2007               [Page 2]


Internet-Draft                DKIM-SSP-REQ                   August 2006


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.




































Thomas                  Expires February 11, 2007               [Page 3]


Internet-Draft                DKIM-SSP-REQ                   August 2006


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 a Author address

   o  First Party Signature: For DKIM, a first party signature is a
      valid signature where the domain tag (d=) matches (as defined in
      [DKIM]) the first party address

   o  Third Party Signature: For DKIM, 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.

























Thomas                  Expires February 11, 2007               [Page 4]


Internet-Draft                DKIM-SSP-REQ                   August 2006


3.  Introduction

   The DomainKeys Identified Mail working group is chartered to create a
   base signing mechanism for email.  This work is contained in
   draft-ietf-dkim-base-04.txt.  In addition there are two other
   documents draft-ietf-dkim-overview-00.txt and
   draft-ietf-dkim-threats-03.txt 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 generally there is no a
   priori knowledge of other domains so the safe assumption is the
   lowest common denominator which is no authentication at all.  Thus a
   protocol needs to be developed which can allow a DKIM message
   verifier to determine the DKIM posture of the domain for messages it
   receives which arrive without a valid DKIM signature.

   This draft is organized into two main sections: a Usage Scenario
   section which attempts to describe some common usage scenarios that
   DKIM is likely to be deployed in and the problems that are not solved
   by DKIM alone.  The second is the Requirements that arise because of
   those usage scenarios, in addition more basic protocol requirements.






















Thomas                  Expires February 11, 2007               [Page 5]


Internet-Draft                DKIM-SSP-REQ                   August 2006


4.  Use Scenarios

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

   There seems to be a class of mail -- mostly transactional mail from
   high value domains -- that are the target of phishing attacks.  In
   particular, the 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 guarantee that their mail is
   always from them.  The first step is, of course, to use DKIM-base to
   sign all of their outgoing mail so that a receiver can make a
   positive determination that the mail is from the domain holder in
   question.

   The problem with this scenario is that 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.  An information service which
   allowed a receiver to query for those practices and expectations
   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 use this information to treat such questionable mail
   with prejudice.

   Note that for the foreseeable future, DKIM signature breakage for
   unrestricted use patterns (ie with users and especially where users
   are members of mailing lists) will likely suffer occassional damage
   in transit.  While probably not a large percentage of total traffic,
   the kind (quality) of breakage may be significant for certain usage
   patterns.  As such, this scenario defines a more limited situation
   where the risk of a legitimate piece of mail being mislabeled as
   unsigned outweights the risk of illegitimate mail being delivered in
   the eyes of the sender.

   1.  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 state of
       affairs.






Thomas                  Expires February 11, 2007               [Page 6]


Internet-Draft                DKIM-SSP-REQ                   August 2006


4.2.  Scenario 2: DKIM Signing Complete

   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 contained a valid DKIM signature.  Given the likelihood of
   signature damage in the current mail infrastructure as noted above, a
   domain can fit the DKIM signing complete scenario without wanting to
   take the risks associated with the more narrow scope of use in the
   previous scenario.  A receiver, on the other hand, may be able to
   take advantage of the knowledge the domain's practice of signing all
   mail in order to use it to bias filters against the unexpected
   arrival of 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 a domain
   holder to have the ability to be able to enumerate a list of domains
   that should be treated as equivalent to a first party signature from
   the domain holder itself.  One obvious use scenario is a domain
   holder for 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.

   That said, DKIM uses DNS to store selectors.  Thus there is always
   the ability for a domain holder to delegate all or parts of the
   _domainkey subdomain to a third party of the domain holder's
   choosing.  That is, the domain holder can always 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 further constrain
   the third party to only be able to sign messages on behalf of the
   benefits subdomain.

   There have been concerns expressed about how well this would scale
   when the third party is, say, a large ISP that signs for thousands of
   domains.  There has been concern about how well this would work for
   multiple delegations.  Lastly, using NS delegations requires that the
   signer actively cooperate with the domain for whom it is signing.
   That is, it requires that the signer actively manage the _domainkey
   delegation for the domain holder.  A domain holder would not, for
   example, be able to make a statement that ISP.com signing on its



Thomas                  Expires February 11, 2007               [Page 7]


Internet-Draft                DKIM-SSP-REQ                   August 2006


   behalf was acceptable without ISP.com's cooperation.  This by
   extension also applies to other third parties that a domain might
   like to effectively "whitelist" such as mailing lists that re-sign
   mail that the domain holder holds in esteem.















































Thomas                  Expires February 11, 2007               [Page 8]


Internet-Draft                DKIM-SSP-REQ                   August 2006


5.  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 possible.

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








Thomas                  Expires February 11, 2007               [Page 9]


Internet-Draft                DKIM-SSP-REQ                   August 2006


5.3.  Practice and Expectation Requirements

   In this section, a Practice is defined as a true statement according
   to the domain holder of its intended externally viewable behavior.
   An Expectation combines with a Practice to convey what the domain
   holder considers the likely outcome of the survivability of the
   Practice at a receiver.  For example, a Practice that X is true when
   it leaves the domain, and an Expectation that 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 RFC2822.From address in the context of
        DKIM.  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 the domain
        doesn't send mail.

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

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

           [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
        for signing its messages to a non-related domain in such a way
        that it does not require active participation by the non-related
        domain.  That is, the published information MUST have a way to
        specify the domains that are allowed to sign on its behalf.

   6.   Practices and Expectations MUST be presented as an information
        service from the sender to be consumed as an added factor to the
        receiver's local policy.  In particular a Practice or
        Expectation MUST NOT specify any particular disposition stance
        that the receiver should follow.

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



Thomas                  Expires February 11, 2007              [Page 10]


Internet-Draft                DKIM-SSP-REQ                   August 2006


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

   8.   The Protocol is not required to publish a Practice of any/all
        unreleated third parties that MUST NOT sign on the domain
        holder's behalf.

           [INFORMATIVE NOTE: this is essentially saying that the
           protocol doesn't have to concern itself with being a
           blacklist repository.]

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

   10.  [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]

5.4.  Extensibility and Forward Compatibilty Requirements

   1.  The Protocol MUST NOT extend to any other than DKIM for email at
       this time.

   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













Thomas                  Expires February 11, 2007              [Page 11]


Internet-Draft                DKIM-SSP-REQ                   August 2006


6.  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 order of a constant.

   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.



































Thomas                  Expires February 11, 2007              [Page 12]


Internet-Draft                DKIM-SSP-REQ                   August 2006


7.  IANA Considerations

   This document makes no request of IANA.

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













































Thomas                  Expires February 11, 2007              [Page 13]


Internet-Draft                DKIM-SSP-REQ                   August 2006


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













































Thomas                  Expires February 11, 2007              [Page 14]


Internet-Draft                DKIM-SSP-REQ                   August 2006


9.  Acknowledgements

   free to good home
















































Thomas                  Expires February 11, 2007              [Page 15]


Internet-Draft                DKIM-SSP-REQ                   August 2006


10.  References

10.1.  Normative References

10.2.  Informative References














































Thomas                  Expires February 11, 2007              [Page 16]


Internet-Draft                DKIM-SSP-REQ                   August 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








































Thomas                  Expires February 11, 2007              [Page 17]


Internet-Draft                DKIM-SSP-REQ                   August 2006


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





Thomas                  Expires February 11, 2007              [Page 18]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/