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

Versions: 00 01 02 draft-ietf-dkim-ssp

pre-MASS                                                       E. Allman
Internet-Draft                                            Sendmail, Inc.
Expires:  January 10, 2006                                  July 9, 2005


                       DKIM Sender Signing Policy
                        draft-allman-dkim-ssp-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 January 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transport Agents (MTAs) or Mail
   User Agents (MUAs).  The primary DKIM protocol is described in [ID-
   DK-BASE].  This document describes the policy records that senders
   may use to advertise how they sign their outgoing mail, and how
   verifiers should access and interpret those results.




Allman                  Expires January 10, 2006                [Page 1]


Internet-Draft                  DKIM SSP                       July 2005


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

(Unresolved Issues/To Be Done)

   Security Considerations needs further work.

   Need to add new and check existing ABNF.

   DKP RR needs to be defined.

   Text structure of document needs to be examined; this is a quick
   slash-and-burn approach.  Stop signs indicate sections that haven't
   even been approached yet.

CONVERSION DISCLAIMER

   This initial version that is being submitted as an IETF Internet-
   Draft has been converted over to RFC format by Dave Crocker.  Besides
   the many rough edges to the resulting format of the document, he
   suspects there also might be some more serious errors, such as sub-
   sections being at the wrong level.  These errors will be repaired as
   soon as they are reported.

























Allman                  Expires January 10, 2006                [Page 2]


Internet-Draft                  DKIM SSP                       July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Language and Terminology . . . . . . . . . . . . . . . . . . .  4
     2.1   Originator Address . . . . . . . . . . . . . . . . . . . .  4
     2.2   Suspicious . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of DKIM . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Query and record format  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11






































Allman                  Expires January 10, 2006                [Page 3]


Internet-Draft                  DKIM SSP                       July 2005


1.  Introduction

   DomainKeys Identified Mail (DKIM) [ID-DK-BASE] defines a method
   whereby email senders ("signers") may sign their outgoing messages
   with a secret key that can be checked by a receiver ("verifier") to
   determine whether the signer was authorized to use the sending domain
   name.  The method used is based on well-known public-key cryptography
   methods.

   However, the legacy of the Internet is such that not all messages
   will be signed, and the absence of a signature on a message is not an
   a priori indication of forgery.  In fact, during early phases of
   deployment it must be expected that most messages will remain
   unsigned.  However, some senders may choose to sign all of their
   outgoing mail, for example, to protect their brand name.  Such
   signers must be able to advertise to verifiers that messages claiming
   to be from them that are not signed are forgeries.  This is the topic
   for sender signing policy.

   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822], the verifier of a message MUST determine whether
   messages from a particular sender are expected to be signed, and what
   signatures are acceptable.  In particular, whether a domain is
   participating in DKIM, whether they are testing, and whether it signs
   all outbound email must be communicated to the verifier.  Without
   such a mechanism, the benefit of message signing techniques such as
   DKIM is limited since unsigned messages will always need to be
   considered to be potentially legitimate.  This determination is
   referred to as a Sender Signing Policy Check.

   Sender Signing Policies MAY be expressed on behalf of an entity which
   may be a domain or an individual address.  Expression of signing
   policy on behalf of individual addresses will, of course, entail
   additional key server transaction load.

   Conceivably, such policy expressions might be imagined to be extended
   in the future to include information about what hashing algorithms a
   domain uses, what kind of messages might be sent (e.g., bulk vs.
   personal vs. transactional), etc.  Such concerns are out of scope of
   this standard; because of the need for outside auditing they fall
   under the purview of reputation and accreditation.

2.  Language and Terminology

2.1  Originator Address

   The email address in the "From" header field of a message [RFC2822],
   or if and only if the From header field contains multiple addresses,



Allman                  Expires January 10, 2006                [Page 4]


Internet-Draft                  DKIM SSP                       July 2005


   the email address in the "Sender" header field.

      o An "Alleged Signer" is the identify of the signer claimed in the
      DKIM-Signature header field in a message received by a verifier;
      it is "alleged" because it has not yet been verified.

      o An "Alleged Sender" is the Originator Address of a message
      received by a verifier; it is "alleged" because it has not yet
      been verified.

      o A "Sender Signing Policy" (or just "policy") is a machine-
      readable record published by the Alleged Sender which includes
      information about whether that sender signs all, some, or none of
      their email.  It must be considered together with the "key"
      records, which advertise the public keys associated with the
      Alleged Sender.


2.2  Suspicious

   Messages that fail an initial signature verification step (either by
   an incorrect signature or a lack of signature) and also a further
   Sender Signing Policy check are referred to as "Suspicious".  The
   handling of such messages is at the discretion of the verifier or
   final recipient.  "Suspicious" applies only to the DKIM layer; a
   verifier may decide the message should be accepted on the basis of
   other information beyond the scope of this document.  Conversely,
   messages deemed non-Suspicious may be rejected for other reasons.

   Some terminology used herein is derived directly from [ID-DK-BASE].
   Briefly,

      o A "signer" is the agent that signs a message.  In normal cases
      it will probably correspond closely with the original author of
      the message or an agent working on the author's behalf.  However,
      third parties are often legitimately involved with mail sending,
      and hence it is reasonable for what may seem at first glance to be
      an unaffiliated third party might reasonably send mail on behalf
      of another domain.  Hence, "signer" refers only to the
      administrative authority that has the secret key necessary to sign
      the message.  In particular, that secret key may have been
      transferred to them or otherwise delegated to them by the alleged
      sender.

      o A "verifier" is the agent that verifies a message by checking
      the actual signature against the message itself and the public key
      published by the alleged signer.  The verifier also looks up the
      Sender Signing Policy published by the alleged sender if the



Allman                  Expires January 10, 2006                [Page 5]


Internet-Draft                  DKIM SSP                       July 2005


      message is not correctly signed by the Alleged Sender.

      o A "selector" specifies which of the keys published by an Alleged
      Signer or Sender should be queried.  It is essentially a way of
      subdividing the address space to allow a single sending domain to
      publish multiple keys.


3.  Overview of DKIM

   This section is informative only and MUST NOT be treated as
   normative.  The actual specification is described in [ID-DK-BASE] and
   must be consulted.

   Briefly, when a verifier receives a message, they examine the header
   field of that message to see if it includes one or more DKIM-
   Signature header fields.  If it does, the authenticity of that
   message may be validated using conventional cryptographic techniques.
   However, if the verifier receives a message containing no valid DKIM-
   Signature header fields, it must proceed with the algorithms defined
   in this document.

4.  Operation

   Sender Signing Policy Checks MUST be based on the Originator Address.
   If the message contains a valid signature on behalf of the Originator
   Address no Sender Signing Policy Check need be performed:  the
   verifier SHOULD NOT look up the Sender Signing Policy and the message
   SHOULD be considered non-Suspicious.

   Verifiers checking messages that do not have at least one valid
   signature MUST perform a Sender Signing Policy Check by doing a DNS
   query to the domain specified by the Originator Address.  The query
   MUST be for the search key "_policy._domainkey.<domain>", where
   <domain> is the domain of the Originator Address.  The query may
   return either a DKSSP record or a TXT record; the DKSSP record MUST
   override the TXT record.

   The result of a Sender Signing Policy Check is one of four possible
   policies:

      (1) Some messages from this entity are not signed; the message
      SHOULD be presumed to be legitimate in the absence of a valid
      signature.  This is the default policy.z

      (2) All messages from this entity are signed; all messages from
      this entity SHOULD have a valid signature, either directly on
      behalf of the originator or on behalf of a third party (e.g., a



Allman                  Expires January 10, 2006                [Page 6]


Internet-Draft                  DKIM SSP                       July 2005


      mailing list or an outsourcing house) handling the message.

      (3) All valid messages from this entity are signed, and SHOULD
      have a valid signature from this entity.  Third-party signatures
      SHOULD not be accepted.

      (4) Signing policy for this domain is expressed at the individual
      address level.  A second Sender Signing Policy Check should be
      performed specifying the individual address.

      (5) This Alleged Sender never sends mail at all.

   If a message is encountered by a verifier without a valid signature
   from the Originator Address, the policy results MUST be interpreted
   as follows:

      If the result of the check is policy (1) described above, the
      message MUST be considered non-Suspicious.

      If the result of the check is policy (2), and any verifiable
      signature is present from some signer other than the Originator
      Address in the message, the message SHOULD be considered non-
      Suspicious.

      If the result of the check is policy (3), the message MUST be
      considered suspicious.

      If the result of the check is policy (4), a second Sender Signing
      Policy Check SHOULD be performed based on the entire Originator
      Address and interpreted using the above steps.  If the result of
      that check is policy (4), the signing policy for the originator is
      misconfigured, and the message SHOULD be considered non-
      Suspicious.

      If the Sender Signing Policy record does not exist, verifier
      systems MUST assume that some messages from this entity are not
      signed and the message SHOULD NOT be considered to be Suspicious.


5.  Query and record format

   Signing policy records for a domain are published in key servers as
   the "_policy" selector.  Signing policy records for individual
   addresses are published as the "user._policy" selector.

      NON-NORMATIVE RATIONALE:  Use of a synthetic selector allows non-
      DNS based access for signer policies.




Allman                  Expires January 10, 2006                [Page 7]


Internet-Draft                  DKIM SSP                       July 2005


   To avoid a Denial-of-Service attack, signer policy searches for
   signing policy checks of very deeply nested domains MUST strip off
   all but the last five components of a domain name.  If a policy
   record is not found, the verifier MUST repeat the request to
   successively higher levels of the domain hierarchy until the root is
   reached.  This allows subdomains to inherit the signing policy of
   their parent domains without allowing attackers to specify extremely
   deep subdomains such as
   "a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com".
   If presented with such a signing domain in a DKIM-Signature header
   field, the search for a policy record would start at
   "x.y.z.example.com" and proceed upwards.  Verifiers MUST stop
   searching at the first policy record they encounter.

      NON-NORMATIVE DISCUSSION:  It seems like this limitation should be
      part of the DNS binding rather than a general restriction.

   Signing policy records follow the tag-value syntax described in [ID-
   DK-BASE].  Tags used in signing policy records are as follows:

      o= Outbound signing policy for the entity (plain-text; OPTIONAL,
      default is "~").  Possible values are as follows:

         ~ The entity signs some but not all email.

         - All mail from the entity is signed; unsigned email MUST NOT
         be accepted, but email signed by a third party SHOULD be
         accepted.

         !  All mail from the entity is signed; third-party signatures
         SHOULD NOT be accepted

         .  This entity never sends email.  The "." policy can be used
         to "short circuit" searches from subdomains; for example, the
         "ad.jp" domain might use this.  If an initial policy search
         receives this policy then the email SHOULD NOT be accepted; if
         found while searching parent domains then the search should
         terminate as though no policy record was found.

         ^ Repeat query at user level.  This value MUST NOT be used in
         user-level policy records.

      t= A vertical-bar separated list of flags (plain-text; OPTIONAL,
      default is that no flags are set).  Flag values are:

         y -- The entity is testing signing policy, and the verifier
         SHOULD NOT consider a message suspicious based on the record.




Allman                  Expires January 10, 2006                [Page 8]


Internet-Draft                  DKIM SSP                       July 2005


      n= Human readable notes regarding the record (quoted-printable
      with semicolon encoded in addition to the standard characters;
      OPTIONAL, default is no notes).

      r= Email address for reports and inquiries regarding the signing
      policy for this entity (plain-text; OPTIONAL, default is no
      contact address available).

      u= Reserved for future reference to a URI to provide more detailed
      policy information.

   When represented in DNS, signing policy checks MUST search for a
   DKSSP (DomainKey Sender Signing Policy) RR type first.  If no DKSSP
   RR is found, signing policy checks MUST search for a TXT RR type.

6.  IANA Considerations

   Use of the _domainkey prefix in DNS records will require registration
   by IANA.

   Use of the _policy prefix in DNS records will require registration by
   IANA.

   The DKSSP RR type must be registered by IANA.

7.  Normative References

   [ID-DK-BASE]
              Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)",
              draft-allman-dkim-base-00 (work in progress), July 2005.

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














Allman                  Expires January 10, 2006                [Page 9]


Internet-Draft                  DKIM SSP                       July 2005


Author's Address

   Eric Allman
   Sendmail, Inc.
   6425 Christie Ave, Suite 400
   Emeryville, CA  94608
   USA

   Phone:  +1 510 594 5501
   Email:  eric+dkim@sendmail.org
   URI:








































Allman                  Expires January 10, 2006               [Page 10]


Internet-Draft                  DKIM SSP                       July 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

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


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Allman                  Expires January 10, 2006               [Page 11]


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