Internet DRAFT - draft-akagiri-dmarc-virtual-verification

draft-akagiri-dmarc-virtual-verification







Applications Area Working Group                              G. Yasutaka
Internet-Draft                                             Rakuten, Inc.
Intended status: Informational                                T. Akagiri
Expires: January 29, 2018                                   Regumi, Inc.
                                                               D. Kodama
                                                            BIGLOBE Inc.
                                                                K. Okada
                                                        Lepidum Co. Ltd.
                                                           July 28, 2017


             DMARC verification without record definitions
            draft-akagiri-dmarc-virtual-verification-02.txt

Abstract

   While DMARC is a powerful architecture to protect email users from
   malicious email activities, its deployment is still a work in
   progress.  To encourage further adoption of DMARC, in this draft we
   propose an incremental deployment procedure.

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 January 29, 2018.

Copyright Notice

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



Yasutaka, et al.        Expires January 29, 2018                [Page 1]

Internet-Draft         DMARC virtual verification              July 2017


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     3.2.  DMARC verification without DMARC records. . . . . . . . .   5
   4.  The Virtual DMARC Record  . . . . . . . . . . . . . . . . . .   6
   5.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security consideration  . . . . . . . . . . . . . . . . . . .   7
   7.  Privacy consideration . . . . . . . . . . . . . . . . . . . .   7
   8.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  01 revision  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Currently, there are several email sender validation technologies
   such as SPF and DKIM, which are independent from each other.  There
   is also a need for email verification frameworks to handle the email
   authentication results provided by those validation technologies in a
   unified manner.  DMARC is one of the technologies that provides such
   a capability.

   Although DMARC is an effective technology to protect email users from
   malicious activities such as phishing or malware, at this moment its
   deployment is a work in progress.  A survey[ReturnPath] indicates
   that by the end of 2015, less than 30% of top global companies have
   published DMARC records.  To validate incoming emails properly on the
   receiving MTA side, it is desirable that more domains publish DMARC
   records.

   At the same time, the adoption of SPF and DKIM is widespread, and,
   especially for email receivers, it is valuable to utilize the
   validation results of those technologies.  From the view point of
   email receivers, the main goals of adopting an email verification
   framework are:




Yasutaka, et al.        Expires January 29, 2018                [Page 2]

Internet-Draft         DMARC virtual verification              July 2017


   1.  To identify malicious emails and apply policies

   2.  To verify non-malicious emails as authorized

   This draft focuses on the second goal.

   In this draft, we propose a default verification for domains that do
   not declare DMARC resource records.  This default verification is
   called "virtual verification(s)" in this draft.  With virtual
   verifications, receivers are able to validate emails from domains not
   publishing DMARC records.  This approach allows receiving MTAs to
   validate email senders by utilizing virtual DNS resource records
   populated with default values, and notify email users of the
   authenticity of email senders in a manner compatible with DMARC.

2.  Terminology and Definitions

   o  virtual DMARC record: DMARC record virtually created to verify
      domains that do not publish DMARC records

   o  regular verification: DMARC RFC7489 verification

   o  virtual verification: verification leveraging virtual DMARC
      records to verify emails which would potentially be "dmarc=pass"

3.  Overview

3.1.  Problem Statement

   As described in Section 1, currently the adoption rate of DMARC
   remains low on the email sender side.  This means that operators of
   receiver MTAs have little incentive to introduce DMARC verifiers into
   their MTAs.  DMARC needs implementation on both sender and receiver
   sides, i.e.  email senders have to publish DMARC TXT records on their
   DNS servers, while email receivers have to enable DMARC verification
   on their MTAs.  Thus, the deployment of DMARC is a chicken-and-egg
   problem between email senders and receivers.

   There are situations where emails from domains that do not have DMARC
   records can be treated as "dmarc=pass".  In [RFC7489], the conditions
   for adding "dmarc=none" to Authentication-Results are:

   1.  No DMARC records are defined for email sender domains.

   2.  DMARC records are defined with "p=none" and DMARC verification
       did not pass.





Yasutaka, et al.        Expires January 29, 2018                [Page 3]

Internet-Draft         DMARC virtual verification              July 2017


   Out of the conditions above, on the first condition there should be
   plenty of emails which would potentially be marked as "dmarc=pass".
   Those emails are from domains that have valid SPF records or DKIM
   signatures and validated as authorized with SPF or DKIM, while
   RFC5322.From fields of the emails are aligned with SPF or DKIM
   identifiers.

                  |          |   SPF or DKIM    |
                  +----------+--------+---------+
                  |          | Align  |Not-Align|
                  +------+---+--------+---------+
                  |      |   |        |         |
                  |      |Yes|  Pass  | None(1) |
                  |DMARC |   |        |(p=none) |
                  |Record|   |        |         |
                  |      +---+--------+---------+
                  |      |No |None(2) | None(3) |
                  +------+---+--------+---------+

                  Figure 1: DMARC Authentication-Results

   Figure 1 illustrates the relationship between verification conditions
   and Authentication-Results.  There are three conditions where the
   Authentication-Results are marked as None via DMARC regular
   verification.  The first one is the condition where there is a DMARC
   record with p tag set to 'none' on a sender domain and the domain is
   not aligned with the email RFC5322.From field (None(1) in Figure 1).

   The other two conditions are where the sender domains do not declare
   DMARC records on their DNS servers.  In the first case, None is set
   when DKIM or SPF passes and the identifier aligns but no DMARC
   records are defined on the sender domain (None(2)).  In the second
   case, even if valid DMARC records are declared for the sender
   domains, regular DMARC verification will fail (None(3)).  Regular
   DMARC verification treats None(2) and None(3) in Figure 1 as the same
   "None", but the authenticity of received emails is different in each
   case.

   According to an analysis performed by Re:gumi with a Japanese
   ISP([RegumiDmarcAnalysys]), the proportion of domains which can be
   verified as legitimate by DMARC rises to 41.9% after including the
   domains which potentially can be treated as legitimate (None(2)).

   In this draft, we propose to explicitly mark emails which are
   potentially "dmarc=pass", but are not marked as such via regular
   DMARC verification (None(2)), as "dmarc=pass".  This approach is
   current practice in some email receiver MTAs.




Yasutaka, et al.        Expires January 29, 2018                [Page 4]

Internet-Draft         DMARC virtual verification              July 2017


3.2.  DMARC verification without DMARC records.

   Figure 2 is the state diagram of the DMARC virtual verification.

                    +----------+        +-----------+
                    | SPF Pass |        | DKIM Pass |
                    +----+-----+        +-----+-----+
                         |                    |
                         v                    v
                    +----+--------------------+-----+
                    |     DMARC Record exists?      |
                    +-----+-------------------+-----+
                      Yes v                   v No
                   +------+-----+       +-----+------+
                   |   regular  |       |  virtual   |
             +-----+verification|      /|verification|
             |     +------+-----+     / +-----+------+
             v            |          /        |
        +----+-----+      v         /         v
        |  results |   +--+---+    /      +---+--+
        |other than|   | pass +<--+       | none |
        |   pass   |   +------+           +------+
        +----------+


                          Figure 2: State Diagram

   Email receivers SHOULD verify email senders using virtual DMARC
   records when receivers cannot find DMARC records published by the
   email senders.  The regular DMARC verifier just sets Authentication-
   Results to "none" when the receiving MTA cannot find DMARC policy
   records for the sender domain.  In contrast, when verifications of
   SPF or DKIM have passed, the virtual verification validates senders
   against virtual DMARC records populated with _default_ values.  The
   _default_ values of virtual DMARC records are detailed in Section 4.

   Virtual DMARC verification processes received emails in the same
   manner as the regular DMARC verifier does using those default values.
   The Authentication-Result field is set to "dmarc=pass" for email that
   passes virtual DMARC verification and to "dmarc=none" for email that
   does not.

   Inserting "dmarc=pass" into Authentication-Results may cause
   controversy.  From the point of view of email operators, it is
   desirable to differentiate between emails that pass virtual DMARC
   verifications and those that pass regular DMARC verification.
   However, for end users without enough expertise, simply utilizing
   "dmarc=pass" makes it easier to leverage the field.



Yasutaka, et al.        Expires January 29, 2018                [Page 5]

Internet-Draft         DMARC virtual verification              July 2017


4.  The Virtual DMARC Record

   When a email sender does not publish their DMARC record, the virtual
   DMARC verification validates the sender against a virtual DMARC
   record populated with pre-determined values.  This record is referred
   to as "virtual DMARC record" in this draft.

   The values in the virtual DMARC record are listed below (Table 1).

                 +----------+----------------------------+
                 | Tag Name | Virtual DMARC Record Value |
                 +----------+----------------------------+
                 | v        | DMARC1                     |
                 |          |                            |
                 | p        | none                       |
                 |          |                            |
                 | adkim    | s(strict)                  |
                 |          |                            |
                 | aspf     | s(strict)                  |
                 +----------+----------------------------+

                 Table 1: Values for Virtual DMARC records

   These values are determined so that reasonable verifications can be
   performed when the sender has not published their own DMARC records.

   o  version(v): DMARC1

      *  To allow the DMARC verifier to process virtual DMARC records
         properly, the version tag must be set as 'DMARC1'.

   o  policy(p): none

      *  Received emails must be delivered to email destinations unless
         the email sender has published a DMARC record and has set the
         policy in the record to "quarantine" or "reject" explicitly.
         Therefore, the policy(p) must be set to "none".

   o  adkim, aspf: s(strict)

      *  The default alignment modes for DKIM and SPF are "s(strict)".
         An example would be when a hosting provider ("example.com")
         enables DKIM and publishes a DKIM resource record for a
         customer ("aaa.example.com").  In this case, if the DKIM
         alignment mode (adkim) in the virtual record is "r(relaxed)",
         another customer of the hosting provider ("bbb.example.com")
         can pretend to be the owner of "aaa.example.com".  To prevent
         this, we propose the default alignment modes (adkim and aspf)



Yasutaka, et al.        Expires January 29, 2018                [Page 6]

Internet-Draft         DMARC virtual verification              July 2017


         to be "s(strict)" in the virtual DMARC record, as opposed to
         the default value for the regular DMARC record.

5.  Use cases

   Figuring out whether an email is potentially "dmarc=pass" or not
   allows email system operators to evaluate the authenticity of the
   email sender domain.  DMARC evaluates the RFC5322.From, while SPF
   evaluates the RFC5321.Mailfrom and DKIM verifies the signature of
   email senders.  By combining this information, DMARC verification
   helps to establish domain authenticity which can be used as domain
   reputation or whitelisting of email senders.

   Microsoft Office365 employs the same technique as one mentioned in
   this draft ([BestGuessPass]).  They append "dmarc=bestguesspass" to
   the Authentication-Results to indicate the authenticity of received
   emails to receiving MUAs.

6.  Security consideration

   TBD

7.  Privacy consideration

   TBD

8.  Discussion

   o  In this draft, we propose to verify the incoming email messages
      with the virtual records only in the strict mode.  The Office365
      verifier, however, verify in the relax mode.  Are there any
      demands for the interface to configure the verification alignment
      modes and the authentication codes marked in the Authentication-
      Results?

   o  Values "ruf" and "rua" for virtual records need to be decided.
      There would be differing opinions regarding DMARC reports.  One is
      the opinion that reports without explicitly published DMARC
      records are harmful, while another one is that without reports,
      virtual DMARC verification can not be called DMARC.  Currently, we
      are siding with the first opinion in this draft.

   o  Name of the verification








Yasutaka, et al.        Expires January 29, 2018                [Page 7]

Internet-Draft         DMARC virtual verification              July 2017


9.  Acknowledgements

   The authors would like to thank engineers at the Japanese ISPs So-
   net, NIFTY, Biglobe and CNCI especially Mr. Koichi Abe, Mr. Daisuke
   Kodama and Mr. Nickolay Boyadjiev, for their technical advice and
   data analysis.

10.  Change Log

10.1.  01 revision

   o  Removed Roadmap section

   o  Added focus of this document to Introduction and Problem Statement

   o  Added Use cases section

11.  References

11.1.  Normative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <http://www.rfc-editor.org/info/rfc6376>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <http://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <http://www.rfc-editor.org/info/rfc7489>.




Yasutaka, et al.        Expires January 29, 2018                [Page 8]

Internet-Draft         DMARC virtual verification              July 2017


   [RFC7601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7601,
              DOI 10.17487/RFC7601, August 2015,
              <http://www.rfc-editor.org/info/rfc7601>.

11.2.  Informative References

   [BestGuessPass]
              Zink, T., "What is DMARC BestGuessPass in Office 365?",
              n.d., <https://blogs.msdn.microsoft.com/tzink/2015/05/06/
              what-is-dmarc-bestguesspass-in-office-365/>.

   [RegumiDmarcAnalysys]
              "Re:gumi Dmarc Analysis", n.d., <Under Construction>.

   [ReturnPath]
              Return Path, "DMARC Intelligence Report", February 2016,
              <https://returnpath.com/downloads/dmarc-intelligence-
              report/>.

Authors' Addresses

   Genki Yasutaka
   Rakuten, Inc.

   Email: genki.yasutaka@rakuten.com


   Takehito Akagiri
   Regumi, Inc.

   Email: akagiri@regumi.net


   Daisuke Kodama
   BIGLOBE Inc.

   Email: d-kodama@biglobe.co.jp


   Kouji Okada
   Lepidum Co. Ltd.

   Email: okd@lepidum.co.jp







Yasutaka, et al.        Expires January 29, 2018                [Page 9]