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, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [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, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, . 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]