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

Versions: 00 01 02

Applications Area Working Group                               T. Akagiri
Internet-Draft
Intended status: Informational                               G. Yasutaka
Expires: September 15, 2016                                Rakuten, Inc.
                                                                 M. Kase
                                                       NIFTY Corporation
                                                                K. Okada
                                                                K. Maeda
                                                        Lepidum Co. Ltd.
                                                          March 14, 2016


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

Abstract

   DMARC is a powerful architecture to defend mail end users from
   malicious mail activities, but its deployment is still under process.
   To encourage the installations of DMARC, we propose an incremental
   deployment procedure in this document.

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 15, 2016.

Copyright Notice

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



Akagiri, et al.        Expires September 15, 2016               [Page 1]


Internet-Draft         DMARC virtual verification             March 2016


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

1.  Introduction

   Although DMARC is an effective technology to protect email users from
   malicious activities such as phishings or malwares, at this moment
   its deployment seems to require more time.  A survey[ReturnPath]
   indicates that less than 30% of global top companies have published
   DMARC records by the end of 2015.  To validate incoming emails
   properly on the mail receiving domains, it is desirable for more
   domains to declare DMARC records.

   In this draft, we propose a default DMARC verification for the
   domains that do not declare DMARC records.  With this verification,
   receivers are able to validate the emails from the domains not
   publishing DMARC records.  This approach allows MTAs on the mail
   receiving domains to validate mail senders utilizing virtual DMARC
   records filled with default values, and notify mail end receivers of
   the validity of mail senders in the compatible manner with DMARC.

2.  Terminology and Definitions

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




Akagiri, et al.        Expires September 15, 2016               [Page 2]


Internet-Draft         DMARC virtual verification             March 2016


   o  regular verification: DMARC RFC7489 verification

   o  virtual verification: verification leveraging virtual DMARC
      records

3.  Overview

3.1.  Problem Statement

   As described in Section 1, currently the adoption rate of DMARC
   remains low in the mail sender sides.  This means that operators of
   receiver MTAs are not encouraged to introduce DMARC verifiers to
   their MTAs.  DMARC needs operations both on sender sides and receiver
   sides, that is, mail senders have to publish DMARC TXT records on
   their DNS servers, and MTAs on the receiver domains have to enable
   the DMARC verification.  Thus the deployment of DMARC is a "Chicken-
   and-Egg" question between senders and receivers.

   We propose a receiver-driven incremental deployment procedure in this
   document.

3.2.  DMARC verification without DMARC records.

   Figure 1 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 1: State Diagram




Akagiri, et al.        Expires September 15, 2016               [Page 3]


Internet-Draft         DMARC virtual verification             March 2016


   The Mail receiver SHOULD verify the Mail sender with a virtual DMARC
   record when the receiver could not find the DMARC record published by
   the Mail sender.  The regular DMARC verifier just sets the
   Authentication-Results to "none" when the receiving MTA could not
   find the DMARC policy records for the sender.  In contrast, when the
   verification of SPF or DKIM have passed, the virtual verification
   validates the sender against the virtual DMARC record, that is filled
   with the _default_ values.  The content of the virtual DMARC record
   is explained in detail in Section 4.

   The virtual DMARC verification processes received emails in the same
   way the regular DMARC verifier does with those default values.  As to
   the Authentication-Results field of verified email, "pass" is set to
   verified email and "none" to unverified one.

   When a DKIM verification passes, the virtual DMARC verification for
   the same email always passes.  DMARC verification compares the
   RFC5322.from and domains described in the d tags of DKIM-Signature
   field of the received email.  To pass the DKIM verification those two
   fields must be identical.  Therefore, when the DKIM verification
   passes, the virtual verification of DMARC also passes.

4.  The Virtual DMARC Record

   When the mail sender does not publish their DMARC record, the virtual
   DMARC verification validates the sender against an imaginary DMARC
   record that are filled with pre-determined values.  This record is
   referred to as "virtual DMARC record" in this document.

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

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

                 Table 1: Values for Virtual DMARC records

   These values are determined so that the reasonable verification can
   be performed when the sender is not interested in publish their own
   DMARC record.

   o  policy(p): none



Akagiri, et al.        Expires September 15, 2016               [Page 4]


Internet-Draft         DMARC virtual verification             March 2016


      *  The received emails have to be delivered to mail destinations
         unless the mail sender domains publish DMARC records and set
         the policy in the records to "quarantine" or "reject".  So the
         default policy(p) is set to "none".

   o  adkim, aspf: s(strict)

      *  The default alignment modes for DKIM and SPF are "s(strict)".
         When a hosting provider("example.com"), for instance, enables
         DKIM and publish a DKIM resource record for a
         customer("aaa.example.com").  In this situation, if the DKIM
         alignment mode(adkim) in the virtual record is "r(relaxed)",
         another customer("bbb.example.com") can pretend to be
         "aaa.example.com".  This is not the will of the
         "aaa.example.com".  To prevent this situation, the alignment
         modes (adkim and aspf) are "s(strict)" in the virtual DMARC
         record, as opposed to the default value for the regular DMARC
         record.

5.  Use cases

   TBD

6.  Roadmap

   By promoting DMARC, our final goal is to reject emails from domains
   that do not publish DMARC records.  To achieve this goal, we propose
   a three step deployment.

   o  Step1: As proposed in this draft, the policy(p) for the virtual
      DMARC record is set to "none".

   o  Step2: The policy(p) is set to "quarantine".  A new
      Authentication-Result "SoftFail" may be needed to indicate that
      the failure is due to the virtual verification.

   o  Step3: The policy(p) is set to "reject".

7.  Security consideration

   TBD

8.  Privacy consideration

   TBD






Akagiri, et al.        Expires September 15, 2016               [Page 5]


Internet-Draft         DMARC virtual verification             March 2016


9.  Discussions

   o  Currently the virtual verification set the Authentication-Result
      to "pass" when the verification passes.  Is it better to define
      "SoftPass" so that it indicates the "pass" is based on the virtual
      verification?

   o  Values "ruf" and "rua" for the virtual record.

10.  Acknowledgements

   TBD

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

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



Akagiri, et al.        Expires September 15, 2016               [Page 6]


Internet-Draft         DMARC virtual verification             March 2016


11.2.  Informative References

   [ReturnPath]
              Return Path, ., "DMARC Intelligence Report", February
              2016.

Authors' Addresses

   Takehito Akagiri

   Email: takehito@akagiri.com


   Genki Yasutaka
   Rakuten, Inc.

   Email: genki.yasutaka@rakuten.com


   Masaki Kase
   NIFTY Corporation

   Email: kase.masaki@nifty.co.jp


   Kouji Okada
   Lepidum Co. Ltd.

   Email: okd@lepidum.co.jp


   Kaoru Maeda
   Lepidum Co. Ltd.

   Email: maeda@lepidum.co.jp
















Akagiri, et al.        Expires September 15, 2016               [Page 7]


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