idnits 2.17.1 draft-akagiri-dmarc-virtual-verification-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 218: '... Email receivers SHOULD verify email s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2017) is 2461 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5321' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC5598' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC7601' is defined on line 380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area Working Group G. Yasutaka 3 Internet-Draft Rakuten, Inc. 4 Intended status: Informational T. Akagiri 5 Expires: January 29, 2018 Regumi, Inc. 6 D. Kodama 7 BIGLOBE Inc. 8 K. Okada 9 Lepidum Co. Ltd. 10 July 28, 2017 12 DMARC verification without record definitions 13 draft-akagiri-dmarc-virtual-verification-02.txt 15 Abstract 17 While DMARC is a powerful architecture to protect email users from 18 malicious email activities, its deployment is still a work in 19 progress. To encourage further adoption of DMARC, in this draft we 20 propose an incremental deployment procedure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 29, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 60 3.2. DMARC verification without DMARC records. . . . . . . . . 5 61 4. The Virtual DMARC Record . . . . . . . . . . . . . . . . . . 6 62 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security consideration . . . . . . . . . . . . . . . . . . . 7 64 7. Privacy consideration . . . . . . . . . . . . . . . . . . . . 7 65 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. 01 revision . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 11.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Currently, there are several email sender validation technologies 77 such as SPF and DKIM, which are independent from each other. There 78 is also a need for email verification frameworks to handle the email 79 authentication results provided by those validation technologies in a 80 unified manner. DMARC is one of the technologies that provides such 81 a capability. 83 Although DMARC is an effective technology to protect email users from 84 malicious activities such as phishing or malware, at this moment its 85 deployment is a work in progress. A survey[ReturnPath] indicates 86 that by the end of 2015, less than 30% of top global companies have 87 published DMARC records. To validate incoming emails properly on the 88 receiving MTA side, it is desirable that more domains publish DMARC 89 records. 91 At the same time, the adoption of SPF and DKIM is widespread, and, 92 especially for email receivers, it is valuable to utilize the 93 validation results of those technologies. From the view point of 94 email receivers, the main goals of adopting an email verification 95 framework are: 97 1. To identify malicious emails and apply policies 99 2. To verify non-malicious emails as authorized 101 This draft focuses on the second goal. 103 In this draft, we propose a default verification for domains that do 104 not declare DMARC resource records. This default verification is 105 called "virtual verification(s)" in this draft. With virtual 106 verifications, receivers are able to validate emails from domains not 107 publishing DMARC records. This approach allows receiving MTAs to 108 validate email senders by utilizing virtual DNS resource records 109 populated with default values, and notify email users of the 110 authenticity of email senders in a manner compatible with DMARC. 112 2. Terminology and Definitions 114 o virtual DMARC record: DMARC record virtually created to verify 115 domains that do not publish DMARC records 117 o regular verification: DMARC RFC7489 verification 119 o virtual verification: verification leveraging virtual DMARC 120 records to verify emails which would potentially be "dmarc=pass" 122 3. Overview 124 3.1. Problem Statement 126 As described in Section 1, currently the adoption rate of DMARC 127 remains low on the email sender side. This means that operators of 128 receiver MTAs have little incentive to introduce DMARC verifiers into 129 their MTAs. DMARC needs implementation on both sender and receiver 130 sides, i.e. email senders have to publish DMARC TXT records on their 131 DNS servers, while email receivers have to enable DMARC verification 132 on their MTAs. Thus, the deployment of DMARC is a chicken-and-egg 133 problem between email senders and receivers. 135 There are situations where emails from domains that do not have DMARC 136 records can be treated as "dmarc=pass". In [RFC7489], the conditions 137 for adding "dmarc=none" to Authentication-Results are: 139 1. No DMARC records are defined for email sender domains. 141 2. DMARC records are defined with "p=none" and DMARC verification 142 did not pass. 144 Out of the conditions above, on the first condition there should be 145 plenty of emails which would potentially be marked as "dmarc=pass". 146 Those emails are from domains that have valid SPF records or DKIM 147 signatures and validated as authorized with SPF or DKIM, while 148 RFC5322.From fields of the emails are aligned with SPF or DKIM 149 identifiers. 151 | | SPF or DKIM | 152 +----------+--------+---------+ 153 | | Align |Not-Align| 154 +------+---+--------+---------+ 155 | | | | | 156 | |Yes| Pass | None(1) | 157 |DMARC | | |(p=none) | 158 |Record| | | | 159 | +---+--------+---------+ 160 | |No |None(2) | None(3) | 161 +------+---+--------+---------+ 163 Figure 1: DMARC Authentication-Results 165 Figure 1 illustrates the relationship between verification conditions 166 and Authentication-Results. There are three conditions where the 167 Authentication-Results are marked as None via DMARC regular 168 verification. The first one is the condition where there is a DMARC 169 record with p tag set to 'none' on a sender domain and the domain is 170 not aligned with the email RFC5322.From field (None(1) in Figure 1). 172 The other two conditions are where the sender domains do not declare 173 DMARC records on their DNS servers. In the first case, None is set 174 when DKIM or SPF passes and the identifier aligns but no DMARC 175 records are defined on the sender domain (None(2)). In the second 176 case, even if valid DMARC records are declared for the sender 177 domains, regular DMARC verification will fail (None(3)). Regular 178 DMARC verification treats None(2) and None(3) in Figure 1 as the same 179 "None", but the authenticity of received emails is different in each 180 case. 182 According to an analysis performed by Re:gumi with a Japanese 183 ISP([RegumiDmarcAnalysys]), the proportion of domains which can be 184 verified as legitimate by DMARC rises to 41.9% after including the 185 domains which potentially can be treated as legitimate (None(2)). 187 In this draft, we propose to explicitly mark emails which are 188 potentially "dmarc=pass", but are not marked as such via regular 189 DMARC verification (None(2)), as "dmarc=pass". This approach is 190 current practice in some email receiver MTAs. 192 3.2. DMARC verification without DMARC records. 194 Figure 2 is the state diagram of the DMARC virtual verification. 196 +----------+ +-----------+ 197 | SPF Pass | | DKIM Pass | 198 +----+-----+ +-----+-----+ 199 | | 200 v v 201 +----+--------------------+-----+ 202 | DMARC Record exists? | 203 +-----+-------------------+-----+ 204 Yes v v No 205 +------+-----+ +-----+------+ 206 | regular | | virtual | 207 +-----+verification| /|verification| 208 | +------+-----+ / +-----+------+ 209 v | / | 210 +----+-----+ v / v 211 | results | +--+---+ / +---+--+ 212 |other than| | pass +<--+ | none | 213 | pass | +------+ +------+ 214 +----------+ 216 Figure 2: State Diagram 218 Email receivers SHOULD verify email senders using virtual DMARC 219 records when receivers cannot find DMARC records published by the 220 email senders. The regular DMARC verifier just sets Authentication- 221 Results to "none" when the receiving MTA cannot find DMARC policy 222 records for the sender domain. In contrast, when verifications of 223 SPF or DKIM have passed, the virtual verification validates senders 224 against virtual DMARC records populated with _default_ values. The 225 _default_ values of virtual DMARC records are detailed in Section 4. 227 Virtual DMARC verification processes received emails in the same 228 manner as the regular DMARC verifier does using those default values. 229 The Authentication-Result field is set to "dmarc=pass" for email that 230 passes virtual DMARC verification and to "dmarc=none" for email that 231 does not. 233 Inserting "dmarc=pass" into Authentication-Results may cause 234 controversy. From the point of view of email operators, it is 235 desirable to differentiate between emails that pass virtual DMARC 236 verifications and those that pass regular DMARC verification. 237 However, for end users without enough expertise, simply utilizing 238 "dmarc=pass" makes it easier to leverage the field. 240 4. The Virtual DMARC Record 242 When a email sender does not publish their DMARC record, the virtual 243 DMARC verification validates the sender against a virtual DMARC 244 record populated with pre-determined values. This record is referred 245 to as "virtual DMARC record" in this draft. 247 The values in the virtual DMARC record are listed below (Table 1). 249 +----------+----------------------------+ 250 | Tag Name | Virtual DMARC Record Value | 251 +----------+----------------------------+ 252 | v | DMARC1 | 253 | | | 254 | p | none | 255 | | | 256 | adkim | s(strict) | 257 | | | 258 | aspf | s(strict) | 259 +----------+----------------------------+ 261 Table 1: Values for Virtual DMARC records 263 These values are determined so that reasonable verifications can be 264 performed when the sender has not published their own DMARC records. 266 o version(v): DMARC1 268 * To allow the DMARC verifier to process virtual DMARC records 269 properly, the version tag must be set as 'DMARC1'. 271 o policy(p): none 273 * Received emails must be delivered to email destinations unless 274 the email sender has published a DMARC record and has set the 275 policy in the record to "quarantine" or "reject" explicitly. 276 Therefore, the policy(p) must be set to "none". 278 o adkim, aspf: s(strict) 280 * The default alignment modes for DKIM and SPF are "s(strict)". 281 An example would be when a hosting provider ("example.com") 282 enables DKIM and publishes a DKIM resource record for a 283 customer ("aaa.example.com"). In this case, if the DKIM 284 alignment mode (adkim) in the virtual record is "r(relaxed)", 285 another customer of the hosting provider ("bbb.example.com") 286 can pretend to be the owner of "aaa.example.com". To prevent 287 this, we propose the default alignment modes (adkim and aspf) 288 to be "s(strict)" in the virtual DMARC record, as opposed to 289 the default value for the regular DMARC record. 291 5. Use cases 293 Figuring out whether an email is potentially "dmarc=pass" or not 294 allows email system operators to evaluate the authenticity of the 295 email sender domain. DMARC evaluates the RFC5322.From, while SPF 296 evaluates the RFC5321.Mailfrom and DKIM verifies the signature of 297 email senders. By combining this information, DMARC verification 298 helps to establish domain authenticity which can be used as domain 299 reputation or whitelisting of email senders. 301 Microsoft Office365 employs the same technique as one mentioned in 302 this draft ([BestGuessPass]). They append "dmarc=bestguesspass" to 303 the Authentication-Results to indicate the authenticity of received 304 emails to receiving MUAs. 306 6. Security consideration 308 TBD 310 7. Privacy consideration 312 TBD 314 8. Discussion 316 o In this draft, we propose to verify the incoming email messages 317 with the virtual records only in the strict mode. The Office365 318 verifier, however, verify in the relax mode. Are there any 319 demands for the interface to configure the verification alignment 320 modes and the authentication codes marked in the Authentication- 321 Results? 323 o Values "ruf" and "rua" for virtual records need to be decided. 324 There would be differing opinions regarding DMARC reports. One is 325 the opinion that reports without explicitly published DMARC 326 records are harmful, while another one is that without reports, 327 virtual DMARC verification can not be called DMARC. Currently, we 328 are siding with the first opinion in this draft. 330 o Name of the verification 332 9. Acknowledgements 334 The authors would like to thank engineers at the Japanese ISPs So- 335 net, NIFTY, Biglobe and CNCI especially Mr. Koichi Abe, Mr. Daisuke 336 Kodama and Mr. Nickolay Boyadjiev, for their technical advice and 337 data analysis. 339 10. Change Log 341 10.1. 01 revision 343 o Removed Roadmap section 345 o Added focus of this document to Introduction and Problem Statement 347 o Added Use cases section 349 11. References 351 11.1. Normative References 353 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 354 DOI 10.17487/RFC5321, October 2008, 355 . 357 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 358 DOI 10.17487/RFC5322, October 2008, 359 . 361 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 362 DOI 10.17487/RFC5598, July 2009, 363 . 365 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 366 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 367 RFC 6376, DOI 10.17487/RFC6376, September 2011, 368 . 370 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 371 Authorizing Use of Domains in Email, Version 1", RFC 7208, 372 DOI 10.17487/RFC7208, April 2014, 373 . 375 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 376 Message Authentication, Reporting, and Conformance 377 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 378 . 380 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 381 Message Authentication Status", RFC 7601, 382 DOI 10.17487/RFC7601, August 2015, 383 . 385 11.2. Informative References 387 [BestGuessPass] 388 Zink, T., "What is DMARC BestGuessPass in Office 365?", 389 n.d., . 392 [RegumiDmarcAnalysys] 393 "Re:gumi Dmarc Analysis", n.d., . 395 [ReturnPath] 396 Return Path, "DMARC Intelligence Report", February 2016, 397 . 400 Authors' Addresses 402 Genki Yasutaka 403 Rakuten, Inc. 405 Email: genki.yasutaka@rakuten.com 407 Takehito Akagiri 408 Regumi, Inc. 410 Email: akagiri@regumi.net 412 Daisuke Kodama 413 BIGLOBE Inc. 415 Email: d-kodama@biglobe.co.jp 417 Kouji Okada 418 Lepidum Co. Ltd. 420 Email: okd@lepidum.co.jp