Individual submission                                       M. Kucherawy
Internet-Draft                                           Cloudmark, Inc.
Intended status: Experimental                          November 13, 2011
Expires: May 16, 2012


                  DKIM Authorized Third-Party Signers
                      draft-kucherawy-dkim-atps-11

Abstract

   This memo presents an experimental proposal to supplement Domain Keys
   Identified Mail (DKIM) by allowing advertisement of third-party
   signature authorizations on behalf of an email originator.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on May 16, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Kucherawy                 Expires May 16, 2012                  [Page 1]


Internet-Draft            DKIM ATPS Experiment             November 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  E-Mail Architecture Terminology  . . . . . . . . . . . . .  3
   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Queries and Replies  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Extension to DKIM  . . . . . . . . . . . . . . . . . . . .  4
     4.2.  ATPS Query Details . . . . . . . . . . . . . . . . . . . .  4
     4.3.  ATPS Reply Details . . . . . . . . . . . . . . . . . . . .  6
   5.  Interpretation . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Relationship to ADSP . . . . . . . . . . . . . . . . . . . . .  7
   7.  Experiment Process . . . . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  ATPS Tag Registry  . . . . . . . . . . . . . . . . . . . .  8
     8.2.  Email Authentication Method Name Registry Update . . . . .  8
     8.3.  Email Authentication Result Name Registry Update . . . . .  8
     8.4.  DKIM-Signature Tag Specification Registry  . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     9.1.  False Privacy  . . . . . . . . . . . . . . . . . . . . . . 10
     9.2.  Transient Security Failures  . . . . . . . . . . . . . . . 10
     9.3.  Load on the DNS  . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Example Query and Reply . . . . . . . . . . . . . . . 12
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13























Kucherawy                 Expires May 16, 2012                  [Page 2]


Internet-Draft            DKIM ATPS Experiment             November 2011


1.  Introduction

   [DKIM] defines a mechanism for transparent domain-level signing of
   messages for the purpose of declaring that a particular
   Administrative Mail Domain (ADMD) takes some responsibility for a
   message.

   DKIM, however, deliberately makes no binding between the DNS domain
   of the signer and any other identity found in the message.  Despite
   this, there is an automatic human perception that an author domain
   signature (one for which the RFC5322.From domain matches the DNS
   domain of the signer) is more valuable or trustworthy than any other.

   Absent is a protocol by which an ADMD can announce that DKIM
   signatures on its mail added by other ADMDs should also be considered
   trustworthy by verifiers.  This memo presents an experimental
   mechanism for doing so.

2.  Definitions

2.1.  Keywords

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

2.2.  E-Mail Architecture Terminology

   Readers should be familiar with the material and terminology
   discussed in [MAIL] and [EMAIL-ARCH].

3.  Discussion

   Participation in this protocol is divided into three parties:

   o  Authors, whose domains appear in the RFC5322.From field of a
      [MAIL] message;

   o  Signers, who send mail on behalf of Authors and apply [DKIM]
      signatures using their own domains; and

   o  Verifiers, who implement the signature validation procedures
      described in [DKIM].

   An Author participates in this protocol if it wishes to announce that
   a message from it (in the RFC5322.From sense) should be considered
   authentic as long as it bears a signature from any in a set of
   specified domains.  One might, for example, wish to delegate signing



Kucherawy                 Expires May 16, 2012                  [Page 3]


Internet-Draft            DKIM ATPS Experiment             November 2011


   authority for its DNS domain to an approved messaging service
   provider without doing the work of key transfer described in Appendix
   B.1.1 of [DKIM].  This is communicated to Verifiers via a new tag in
   the DKIM signature.

   A Verifier participates in this protocol if it wishes to ensure that
   a message bears one or more signatures from sources approved to sign
   mail on behalf of the Author, and identify for special treatment mail
   that meets (or does not meet) that criterion.

4.  Queries and Replies

   This section describes in detail the queries issued, the replies
   received, and how they should be interpreted and applied.

4.1.  Extension to DKIM

   [DKIM] signatures contain a "tag=value" sequence.  This protocol will
   add additional tags called "atps" and "atpsh".

   When the Signer generates a DKIM signature on behalf of an Author, it
   MUST include an "atps" tag in the signature and include as its value
   the Author's domain name.

   For creating records in the DNS, a hash algorithm needs to be
   selected.  The Signer and the Author have to agree on which hash is
   to be used, since the Author places a corresponding record in its DNS
   and the Signer will have to indicate in its generated signatures
   which hash algorithm the Author is using.  The selected hash
   algorithm MUST be one of the ones registered with IANA as valid for
   use with DKIM (see Section 7.7 of [DKIM]).  The tag name that carries
   the hash name used is "atpsh".  If absent, the Verifier MUST assume
   "sha1".

   The formal syntax definition, per [ABNF]:

      dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name

      dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP key-h-tag-alg

   "domain-name" and "key-h-tag-alg" are imported from [DKIM].

   The registration for these tags can be found in Section 8.

4.2.  ATPS Query Details

   When a [DKIM] signature including an "atps" tag is successfully
   verified, and is considered acceptable to the Verifier according to



Kucherawy                 Expires May 16, 2012                  [Page 4]


Internet-Draft            DKIM ATPS Experiment             November 2011


   any local policy requirements (which are not discussed here or in
   [DKIM]), the Verifier compares the domain name in the value of that
   tag with the one found in the RFC5322.From field of the message.  The
   match MUST be done in a case-insensitive manner.

   If they do not match, the "atps" tag MUST be ignored.

   If they do match, the Verifier issues a TXT query to the DNS at a
   specific name looking for confirmation by the Author that the Signer
   is authorized by the Author to sign mail on its behalf.  Where
   multiple DKIM signatures are present including valid "atps" tags,
   these queries MAY be done in any order or MAY be done in parallel.

   Where the RFC5322.From field contains multiple addresses, this
   process SHOULD be applied if the "atps" tag's value matches any of
   the domains found in that field.  These MAY be done in any order.

   The name for the query is constructed as follows:

   1.  Select the hash algorithm from the "atpsh" tag in the signature.
       If none, the default is "sha1".  If one is specified but does not
       appear in the list registered with IANA as one valid for use with
       DKIM (see Section 7.7 of [DKIM]), abort the query.

   2.  Extract the value of the "d=" tag from the signature.

   3.  Convert any upper-case characters in that string to their lower-
       case equivalents.

   4.  Feed the resulting string to the selected hash algorithm.

   5.  Convert the output of the hash to a string of printable ASCII
       characters by applying base32 encoding as defined in Section 6 of
       [BASE32].  The base32 encoding is used because its output is
       restricted to characters that are legal for use in labels in the
       DNS, and evaluates the same way in the DNS whether encoded using
       uppercase or lowercase characters.

   6.  Append the string "._atps."

   7.  Append the domain name found in the "atps" tag of the validated
       signature.

   The query's formal syntax definition, per [ABNF]:

           atps-query = 1*BASE32 %x2e.5f.61.74.70.73.2e domain-name

           BASE32 = ( ALPHA / %x32-37 )



Kucherawy                 Expires May 16, 2012                  [Page 5]


Internet-Draft            DKIM ATPS Experiment             November 2011


   See Appendix A for an example of a query construction.

4.3.  ATPS Reply Details

   In the descriptions below, the label NOERROR symbolizes DNS response
   code ("rcode") 0, and NXDOMAIN represents rcode 3.  See Section 4.1.1
   of [DNS] for further details.

   At this time, only three possibilities need to be identified in this
   specification:

   o  An answer is returned (i.e.  [DNS] reply code NOERROR with at
      least one answer) containing a valid ATPS reply.  In this case,
      the protocol has been satisfied and the Verifier can conclude that
      the signing domain is authorized by the Author to sign its mail.
      Further queries SHOULD NOT be initiated.

   o  No answer is returned (i.e.  [DNS] reply code NXDOMAIN, or NOERROR
      with no answers), or one or more answers have been returned as
      described above but none contain a valid ATPS reply.  In this
      case, the Signer has not been authorized to act as a third-party
      signer for this Author, and thus the Verifier MUST continue to the
      next query.

   o  An error is returned (i.e. any other [DNS] reply code).  It is no
      longer possible to determine whether or not this message satisfies
      the Author's list of authorized third-party signers.  The Verifier
      SHOULD stop processing and defer the message for later processing,
      such as requesting temporary failure code from the MTA.

   If all queries are completed and return either NXDOMAIN or NOERROR
   with no answers, then the Signer was not authorized by the Author.

   A valid ATPS reply consists of a sequence of tag-value pairs as
   described in Section 3.2 of [DKIM].  The following tag and value is
   the only one currently supported in ATPS records:

   v: Version (plain-text; REQUIRED) This tag defines the version of
      this specification that applies to the ATPS record.  It MUST have
      the value "ATPS1".  ABNF:

      atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
                 ; FWS is imported from [DKIM]








Kucherawy                 Expires May 16, 2012                  [Page 6]


Internet-Draft            DKIM ATPS Experiment             November 2011


5.  Interpretation

   If a Verifier succeeds in confirming that the Author authorized the
   Signer using this protocol, then the Verifier SHOULD evaluate the
   message as though the Signer is the Author.

   This assertion is based on the fact that the Author explicitly
   endorsed the Signer.  Therefore, a module assessing reputation that
   is based on DKIM signature verification SHOULD apply the reputation
   of the Author domain instead of, or in addition to, that of the
   Signer domain.

6.  Relationship to ADSP

   [ADSP] defined a protocol by which an Author can advertise a request
   to message receivers that messages bearing no valid author signature
   be treated with suspicion or even discarded.

   A Verifier implementing both ADSP and ATPS SHOULD treat a message for
   which the ATPS test described above passes as if it were signed by
   the author domain.  That is, a pass of ATPS means a pass for ADSP.

7.  Experiment Process

   The working group that developed DKIM was not convinced that third
   party assertions were critical to DKIM's success, nor were they
   likely to be immediately useful.  However, this was not based on
   actual experience as there is no specific history on this question.
   Thus, this experiment was devised.

   The experimental protocol described here has been implemented as an
   extension to DKIM in two software products, one of which is open
   source and seeing increasingly wide use.  It is included there to
   allow customers of those systems to make use of it should they
   believe such third party assertions are useful to the overall DKIM
   mechanism.  Further adoption as part of the experiment is welcome and
   encouraged.

   Use of the protocol and anecdotes of how it affects the overall DKIM
   experience will be collected by those implementers and the author of
   this memo.  If the response is substantial and positive, advancement
   along the Standards Track might be warranted.

8.  IANA Considerations

   No actions are required by IANA at this time.  The following need
   only be applied if and when this specification reaches the Standards
   Track.



Kucherawy                 Expires May 16, 2012                  [Page 7]


Internet-Draft            DKIM ATPS Experiment             November 2011


8.1.  ATPS Tag Registry

   An Authorized Third Party Signature (ATPS) Tag Registry will be
   created by IANA to enumerate the tags that are valid for use in ATPS
   records.

   New registrations or updates MUST be published in accordance with the
   "Specification Required" guidelines described in
   [IANA-CONSIDERATIONS].  Such registry changes MUST contain the
   following information:

   1.  Name of the tag being registered or updated

   2.  The document where the specification is created or updated

   3.  The status of the tag, one of "current" (tag is in current use),
       "deprecated" (tag is in current use but its use is discouraged),
       or "historic" (tag is no longer in use)

   The registry's sole initial entry is:

       +-----+--------------+---------+
       | Tag | Specified In | Status  |
       +-----+--------------+---------+
       |  v  | [this memo]  | current |
       +-----+--------------+---------+

8.2.  Email Authentication Method Name Registry Update

   The following should be added to the Email Authentication Method Name
   Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]:

   Method  dkim-atps

   Defined In  [THIS MEMO]

   ptype  header

   property  from

   value  contents of the [MAIL] From: header field, with comments
      removed

8.3.  Email Authentication Result Name Registry Update

   The following should be added to the Email Authentication Result Name
   Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]:




Kucherawy                 Expires May 16, 2012                  [Page 8]


Internet-Draft            DKIM ATPS Experiment             November 2011


   Code  none

   Existing/New Code  existing

   Defined In  [AUTHRES]

   Auth Method  dkim-atps

   Meaning  No valid DKIM signatures were found on the message bearing
      "atps" tags.

   Code  pass

   Existing/New Code  existing

   Defined In  [AUTHRES]

   Auth Method  dkim-atps

   Meaning  An ATPS evaluation was performed and a valid signature from
      an authorized third-party was found on the message.

   Code  fail

   Existing/New Code  existing

   Defined In  [AUTHRES]

   Auth Method  dkim-atps

   Meaning  All valid DKIM signatures bearing an "atps" tag either did
      not reference a domain name found in the RFC5322.From field, or
      the ATPS test(s) performed failed to confirm a third-party
      authorization.

   Code  temperror

   Existing/New Code  existing

   Defined In  [AUTHRES]

   Auth Method  dkim-atps

   Meaning  An ATPS evaluation could not be completed due to some error
      that is likely transient in nature, such as a temporary DNS error.
      A later attempt may produce a final result.





Kucherawy                 Expires May 16, 2012                  [Page 9]


Internet-Draft            DKIM ATPS Experiment             November 2011


   Code  permerror

   Existing/New Code  existing

   Defined In  [AUTHRES]

   Auth Method  dkim-atps

   Meaning  An ATPS evaluation could not be completed due to some error
      that is not likely transient in nature, such as a permanent DNS
      error.  A later attempt is unlikely to produce a final result.

8.4.  DKIM-Signature Tag Specification Registry

   The following should be added to the DKIM-Signature Tag Speficication
   Registry established by [DKIM] as per [IANA-CONSIDERATIONS]:

      +-------+-------------+---------+
      | TYPE  | REFERENCE   | STATUS  |
      +-------+-------------+---------+
      | atps  | [THIS MEMO] | current |
      +-------+-------------+---------+
      | atpsh | [THIS MEMO] | current |
      +-------+-------------+---------+

9.  Security Considerations

   This section discusses potential security issues related to this
   experimental protocol.

9.1.  False Privacy

   The fact that the authorized third-party domain name is hashed and
   then encoded with base32 may give some the false sense that the
   relationship between the two parties is somehow protected.  This is
   not the case.  Indeed, the very purpose of this protocol is to make
   it possible for such relationships to be discovered, so such an
   obscuration would make that process more difficult without a shared
   secret delivered out-of-band to message verifiers (which also adds
   further complexity.  Rather, the hash and encode steps are done
   merely to convert any third-party domain name to a fixed width in the
   construction of the DNS query.

9.2.  Transient Security Failures

   Approving a third party signer exposes the Author to the risk that
   the third party signer becomes compromised and then begins to sign
   malicious or nuisance messages on behalf of the Author.  This can



Kucherawy                 Expires May 16, 2012                 [Page 10]


Internet-Draft            DKIM ATPS Experiment             November 2011


   obviously reflect negatively on the Author, and the impact of this
   can become more severe as automated domain reputation systems are
   developed and deployed.  Thorough vetting and monitoring practices by
   Authors of third party signers will likely need to become the norm.

9.3.  Load on the DNS

   A Verifier participating in DKIM, ADSP and ATPS will now issue a
   number of TXT queries to the DNS equal to as many as one (for the
   ADSP query) plus the number of signatures on the message (one for
   each key that is to be verified) plus the number of signatures that
   validated which also bear an "atps" tag.  This is in addition to any
   PTR and A queries the MTA may issue at the time the actual message
   relaying or delivery is initiated.  Obviously this can be burdensome
   on the DNS at both ends, and waiting for that number of queries to
   return when they are issued in parallel could trigger timeouts in the
   MTA.

   An alternative to this that has not yet been explored is the storage
   of the ATPS data at a specific URL tied to the Author's domain name.
   This would alleviate pressure on the DNS at the expense of requiring
   the Author to operate a web server (which has its own security
   implications) and the addition of the establishment of a TCP
   connection.  Moreover, the Verifier would be well advised to
   implement caching of this data to prevent ATPS from being used as a
   denial-of-service vector.

10.  References

10.1.  Normative References

   [ABNF]                 Crocker, D. and P. Overell, "Augmented BNF for
                          Syntax Specifications: ABNF", STD 68,
                          RFC 5234, January 2008.

   [AUTHRES]              Kucherawy, M., "Message Header Field for
                          Indicating Message Authentication Status",
                          RFC 5451, April 2009.

   [BASE32]               Josefsson, S., "The Base16, Base32, and Base64
                          Data Encodings", RFC 4648, October 2006.

   [DKIM]                 Crocker, D., Ed., Hansen, T., Ed., and M.
                          Kucherawy, Ed., "DomainKeys Identified Mail
                          (DKIM) Signatures", RFC 6376, September 2011.

   [DNS]                  Mockapetris, P., "Domain names -
                          implementation and specification", STD 13,



Kucherawy                 Expires May 16, 2012                 [Page 11]


Internet-Draft            DKIM ATPS Experiment             November 2011


                          RFC 1035, November 1987.

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

10.2.  Informative References

   [ADSP]                 Allman, E., Fenton, J., Delany, M., and J.
                          Levine, "DomainKeys Identified Mail (DKIM)
                          Author Domain Signing Practices (ADSP)",
                          RFC 5617, August 2009.

   [EMAIL-ARCH]           Crocker, D., "Internet Mail Architecture",
                          RFC 5598, October 2008.

   [IANA-CONSIDERATIONS]  Narten, T. and H. Alvestrand, "Guidelines for
                          Writing an IANA Considerations Section in
                          RFCs", BCP 26, RFC 5226, May 2008.

   [MAIL]                 Resnick, P., Ed., "Internet Message Format",
                          RFC 5322, October 2008.

Appendix A.  Example Query and Reply

   This section presents an example of the use of this protocol to query
   for a third-party authorization and discusses the interpretation of
   the result.

   Presume a message for which the RFC5322.From domain is "example.com",
   and it bears two valid signatures, from "one.example.net" and from
   "two.example.net", each with an "atps" tag whose value is
   "example.com", and no "atpsh" tag is present in either.  The
   following actions are taken:

   1.  A SHA1 hash of "one.example.net" is computed and then converted
       to printable form using base32 encoding, resulting in the string
       "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".

   2.  A TXT query is issued to
       "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".

   3.  If a valid reply arrives, the algorithm stops with [AUTHRES]
       result "pass".  If a DNS error code other than NXDOMAIN is
       returned, the algorithm stops with a result of "temperror" or
       "permerror" as appropriate.





Kucherawy                 Expires May 16, 2012                 [Page 12]


Internet-Draft            DKIM ATPS Experiment             November 2011


   4.  A SHA1 hash of "two.example.net" is computed and then converted
       to printable form using base32 encoding, resulting in the string
       "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".

   5.  A TXT query is issued to
       "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".

   6.  If a valid reply arrives, the algorithm stops with [AUTHRES]
       result "pass".  If a DNS error code other than NXDOMAIN is
       returned, the algorithm stops with a result of "temperror" or
       "permerror" as appropriate.

   7.  As there are no valid signatures left to test, the algorithm
       stops with an "unknown" result.

Appendix B.  Acknowledgements

   The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark
   Martinec and Phil Pennock for their review and constructive criticism
   of this proposal.

   The author also wishes to acknowledge Doug Otis and Daniel Black for
   their original draft upon which this work was based.

Author's Address

   Murray S. Kucherawy
   Cloudmark, Inc.
   128 King St., 2nd Floor
   San Francisco, CA  94107
   US

   Phone: +1 415 946 3800
   EMail: msk@cloudmark.com

















Kucherawy                 Expires May 16, 2012                 [Page 13]