Internet DRAFT - draft-otis-dmarc-author-align

draft-otis-dmarc-author-align






dmarc                                                            D. Otis
Internet-Draft                                               Trend Micro
Intended status: Experimental                              March 4, 2015
Expires: September 5, 2015


                           DMARC Author Align
                    draft-otis-dmarc-author-align-01

Abstract

   Deals with DMARC acceptance failures disrupting legitimate and valid
   message distribution affecting millions while attempting to exclude
   From header field domains not aligned with email acceptance methods
   in a manner incompatible with normal email conventions.  DMARC does
   not accommodate recent message structure underscoring the erroneous
   premise of a store-and-forward transport enforcing non-negotiable
   message structure.  Active exploitation of DMARC dependency on flawed
   acceptance practices are further aggravated when its feedback is sent
   to malefactors.  Risks prevented by careful accommodation of
   legitimate and valid messages also better ensures economic, social,
   and civic benefits derived from an open exchange of email.


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

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 September 5, 2015.

Copyright Notice



Otis                    Expires September 5, 2015               [Page 1]

Internet-Draft             DMARC-Author-Align                 March 2015


   Copyright (c) 2015 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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Domain Authorization Issues . . . . . . . . . . . . . . . . . . 3
   3.  Methods For Preventing Disruption . . . . . . . . . . . . . . . 4
     3.1.  Past solution used with Sender-ID . . . . . . . . . . . . . 5
   4.  Why DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Privacy Considerations  . . . . . . . . . . . . . . . . . . 7
     4.2.  Security Considerations . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9























Otis                    Expires September 5, 2015               [Page 2]

Internet-Draft             DMARC-Author-Align                 March 2015


1.  Introduction

   SMTP security via opportunistic DANE TLS
   [I-D.ietf-dane-smtp-with-dane] should soon offer a secure global host
   identity scheme for email.  DNSSEC/DANE overcomes security weaknesses
   found in both routing and message exchange.  While some claim DNSSEC/
   DANE is not practical they also misrepresent weaker methods based on
   IP address authorization or signed message fragments as representing
   domain authentication.  IP address based authorization or potentially
   malformed message fragments can not safely verify a domain is bound
   with a message.  DMARC even offers malefactors feedback which can
   enhance the exploit effectiveness or leak relationship information
   used to facilitate deceptions.  Misleading use of the term
   "authentication" which conflicts with [RFC3552] and [RFC4949] occurs
   with [RFC7001] and [I-D.kucherawy-dmarc-base].


2.  Domain Authorization Issues

   The domain referenced by SPF [RFC7208] or the domain of a DKIM
   [RFC6376] signature has not been a problem since seldom was
   acceptance based on From header field Domain Alignment with those
   used by these two methods.  However, when acceptance is based on From
   header field alignment in the case of [I-D.kucherawy-dmarc-base]
   using either SPF or DKIM related domains, this now disrupts many
   Third-Party Services and deprecates the use of the From header field
   of being able to retain the role of Author.  The disruption becomes
   egregious when messages from the domain's own users are rejected
   based on the erroneous level of this domain's asserted alignment
   practices.  At the strictest alignment level, erroneous assertions
   not only disrupt messages from their users, it also affects
   subscriptions or services for other users of the Third-Party Service.

   SPF normally provides a form of authorization by listing IP addresses
   of authorized outbound servers.  In many cases, these servers
   represent a shared resource used by perhaps thousands of domains.
   SPF is unable to verify an IP address represents the actions of a
   claimed domain which does not meet the definition of "$
   authentication" in [RFC4949].

   DKIM intended to establish increased levels of trust based upon
   verified DKIM signatures controlling acceptance and what a user sees
   within the FROM header field.  But DKIM failed to guard against pre-
   pended header fields to ensure acceptance is not based on verified
   DKIM signatures that don't prevent header field spoofing, especially
   that of the FROM.  This weakness allows malefactors to exploit DKIM
   signature acceptance established by high-volume DKIM domains to spoof
   ANY other domain, even when prohibited within the Signer's network.



Otis                    Expires September 5, 2015               [Page 3]

Internet-Draft             DMARC-Author-Align                 March 2015


   Some argued a requirement that DKIM validation include assurances the
   signed header fields are not invalidly repeated represents a protocol
   layer violation.  Reporting a signature verified by a process that
   MUST examine the entire header field stack as needing such a
   recommended validation be made by a prior unreported and unknown
   process suggests a greater violation, if not in protocol, in trust.
   It took several years for one of the largest service providers to
   notice this oversight long after arguments were made about this risk.
   Ignoring essential header field stack validation that MUST occur
   represents an oversight in the DKIM deployment specifications that at
   one time had been partially addressed by the earlier DMARC
   specifications.  It seems even this validation has been removed by
   what might be described as a misguided insistence such processing
   remains the responsibility of the transport.

   [RFC5321] Section 3.3 clearly indicates messages SHOULD NOT be
   rejected based on perceived defects in [RFC5322] message structure.
   Section 7.1 also warns against preventing spoofing within the SMTP
   transport and suggests much safer PGP or S/MIME, both of which
   benefit by deployment of DANE.  DMARC was developed to curtail
   phishing attempts leading to user attrition with high volume
   transactional services.  Unfortunately, DMARC is being (ab)used to
   lessen phishing attempts related to general user accounts where there
   seems little interest at finding a solution for the problems this
   creates.


3.  Methods For Preventing Disruption

   Conditionally permit Sender header field alignment:  For domains
      handling normal user email, a special DMARC assertion could allow
      policy be established by the Sender header field when present with
      an assumption their users employ Mail User Agents displaying the
      Sender header field.


   Define a new Author header:  A new "Author" header field can be used
      to re-establish the Author role for RFC5322.From domains affected
      by those handling normal user email employing Third-Party services
      sending their messages on their behalf.  For this provision to be
      effective, a practice of re-locating the Author role to this new
      header needs to be established by these third-party services.
      Establishing a new header prevents confusion caused by the use of
      unknown alternatives, such as Reply-To, or Original-From, or
      indirectly with use of Original Authentication Results Header.


   Third-Party Authorization:  A different domain is specifically



Otis                    Expires September 5, 2015               [Page 4]

Internet-Draft             DMARC-Author-Align                 March 2015


      excluded from actions caused by non-alignment when authorized by
      the DMARC domain using [I-D.otis-tpa-label].



   A few large domains have had a high percentage of user accounts
   compromised.  These events gave malefactors access to prior private
   exchanges and contact lists.  Even after accounts were reclaimed,
   malefactors continue sending convincing spoofed messages from other
   sources.  To mitigate harm, some domains have asserted DMARC
   Alignment policies similar to those used by domains that only emit
   transactional messaging where a DMARC recommendation of restricted
   use is normally heeded.  In addition, some domains also recommended
   "reject" rather than "quarantine" as a misalignment response.  In
   conjunction with misleading DMARC alignment assertions, rejection
   becomes a highly disruptive choice.

   Currently, the least disruptive adjustment made by receivers faced
   with Third-Party services used by a RFC5322.From domain is to
   override their policy of "reject" with "quarantine" to allow delivery
   of the message causing users to search through their "quarantine"
   folder for otherwise lost messages.  Alternatively, the From header
   field may replace the Author role with that of the Sender.  Some have
   suggested the From header field contents could be retained in the
   Reply-To header.  Others suggested creating an X-Original-From header
   field which could be given the name Author.

3.1.  Past solution used with Sender-ID

   During the development of Sender-ID, some Mail User Agents combined
   the Sender header field with that of the From header field when
   alignment matched the Sender rather than the From.  The synthesized
   header became "sender address" on behalf of "from address".  A more
   understandable approach would be to always display the Sender header
   field when present and not matching the domain of the From header
   field.  This change would include policy following that of the
   Sender, which is the domain really being trusted and most likely in
   alignment with the acceptance mechanisms.  This change would
   eliminate most of the disruptions now resulting from DMARC while also
   improving security.

   DMARC could include an alignment assertion permitting policy to be
   based on the Sender header.  Those domains that failed to ensure
   against the use of Third party services, could have their policy
   altered by the receivers to permit Sender alignment.  In most cases,
   this would remove the need of users to risk recovering messages from
   their "quarantine" folder.




Otis                    Expires September 5, 2015               [Page 5]

Internet-Draft             DMARC-Author-Align                 March 2015


   It is unfair to place a large burden on receivers and expect them to
   remain cooperative.  Prior to making alignment assertions likely to
   disrupt services handling legitimate messages, it is possible for
   RFC5322.From domains to make assertions which allow compliance with
   normal email handling.  When RFC5322.From domains proactively guard
   against disrupting legitimate messages, receivers are more likely to
   cooperate with their recommendations.  When the asserted policies
   prove disruptive over time, DMARC should offer receivers reasonable
   overrides.


4.  Why DMARC

   Deterrents based upon reputation and/or path based scoring strategies
   that utilize a variety of originating header fields has proved
   ineffective.  These header fields often remain invisible to
   recipients, and contain domains exploited for periods measured in
   hours, to avoid any Whack-A-Mole like response.  Even long term
   reputations have issues due to an intermix of messages from
   compromised accounts.  Content filtering is unable to keep up with
   the polymorphic abuse.  Few recipients will inspect the stack of
   message header fields, or be able to draw useful conclusions from a
   profusion of unfriendly information.  As a result, many recipients
   deal with abuse by sorting messages into groups based on assumed
   sources found in a few originating header fields.

   DMARC represents an open registry that offers domain specific
   guidance for DKIM/SPF alignment sending practices to determine
   whether messages should be delivered, quarantined, or refused.
   However, appropriate actions become unclear whenever Third-Party
   Services are involved.  Although DMARC warns of a potential for
   disruption, the specific handling requested by DMARC is very limited.
   DMARC expects receivers to devise their own special handling to
   mitigate disruptions that DMARC assertions might cause for legitimate
   messaging.  This is unfortunate, since the necessary feedback is
   given to the DMARC asserting domain and not to the cooperating
   receivers.

   When a Third Party domain does not employ DKIM or SPF or does not
   include Authentication-Results header fields [RFC7001] or perhaps
   [I-D.kucherawy-original-authres] (OAR) or its "X-" version could
   allow authorizations to be exploited.  For Third Party domains not
   applying DMARC but capture the OAR, past compliance with DMARC based
   on the OAR can be made a requirement for authorization.

   While conceivably Domain Alignment might just rely on the content of
   the Original-Authentication-Results header, whether to trust this, or
   any other message content can not be based on the mere acceptance of



Otis                    Expires September 5, 2015               [Page 6]

Internet-Draft             DMARC-Author-Align                 March 2015


   the message alone.  Whether false content even effects message
   acceptance would be difficult to determine.  Only the DMARC asserting
   domain is able to make this type of determination based on their
   knowledge of outbound messages and corrections needed based on DMARC
   feedback.

4.1.  Privacy Considerations

   Unless all valid Third-Party Domains have been authorized or allowed
   a suitable From header field alternative, personally identifiable
   information will be exchanged within the DMARC feedback.  This
   feedback can unintentionally expose private exchanges made on behalf
   of the RFC5322.From domain's users.  To the greatest extent possible,
   this feedback information should not be shared with other domains not
   offering the information.  This feedback can even identify mailing-
   list subscribers that never sent any message to the list, or invoices
   made on behalf of an accountant's client.

4.2.  Security Considerations

   This draft extends Domain Alignment validation practices that depend
   on DKIM [RFC6376] or SPF [RFC7208].  Most related security matters
   are discussed in those specifications.  Additional considerations are
   also included in [RFC6377].  Some receivers mistakenly bypass
   validation of the [RFC5322] header fields because a signature from a
   Trusted Domain had been confirmed as perhaps suggested in [RFC5863].
   Validation of the header stack MUST NOT be omitted unless the message
   is not accepted for other reasons.

   Services that depend only upon path authorizations might permit the
   RFC5322.From domain to be spoofed and obtain acceptance.  During such
   events, the RFC5322.From domain might need to retract its
   authorization from the service.  For this reason, path related
   validation based on IP addresses should only be used as a carefully
   monitored interim solution.


5.  Acknowledgements



6.  References

6.1.  Normative References

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




Otis                    Expires September 5, 2015               [Page 7]

Internet-Draft             DMARC-Author-Align                 March 2015


   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", RFC 3552, July 2003.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

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

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

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

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

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

   [RFC7001]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7001, September 2013.

6.2.  Informative References

   [I-D.ietf-dane-smtp-with-dane]
              Dukhovni, V. and W. Hardaker, "SMTP security via
              opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-14
              (work in progress), February 2015.

   [I-D.kucherawy-dmarc-base]
              Kucherawy, M. and E. Zwicky, "Domain-based Message
              Authentication, Reporting and Conformance (DMARC)",
              draft-kucherawy-dmarc-base-13 (work in progress),
              February 2015.

   [I-D.kucherawy-original-authres]



Otis                    Expires September 5, 2015               [Page 8]

Internet-Draft             DMARC-Author-Align                 March 2015


              Chew, M. and M. Kucherawy, "Original-Authentication-
              Results Header Field", draft-kucherawy-original-authres-00
              (work in progress), February 2012.

   [I-D.otis-tpa-label]
              Otis, D. and D. Black, "Third-Party Authorization Label",
              draft-otis-tpa-label-05 (work in progress), March 2015.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4954]  Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", RFC 4954, July 2007.

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

   [RFC5863]  Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development,
              Deployment, and Operations", RFC 5863, May 2010.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", BCP 167, RFC 6377, September 2011.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              April 2014.


Author's Address

   Douglas Otis
   Trend Micro



Otis                    Expires September 5, 2015               [Page 9]

Internet-Draft             DMARC-Author-Align                 March 2015


   10101 N. De Anza Blvd
   Cupertino, CA  95014
   USA

   Phone: +1.408.257-1500
   Email: doug_otis@trendmicro.com













































Otis                    Expires September 5, 2015              [Page 10]