idnits 2.17.1 draft-vesely-authmethod-dnswl-11.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** 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 289: '...h the DO bit set MUST NOT be taken to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2019) is 1655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Vesely 3 Internet-Draft October 15, 2019 4 Intended status: Informational 5 Expires: April 17, 2020 7 DNSWL Email Authentication Method Extension 8 draft-vesely-authmethod-dnswl-11 10 Abstract 12 This document describes an additional Email Authentication Method 13 compliant with RFC 8601. The method consists in looking up the 14 sender's IP address in a DNS whitelist. 16 This document does not consider black lists. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 17, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Method Details . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. TXT Record Contents . . . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 5.1. Security of DNSSEC Validation . . . . . . . . . . . . . . 6 58 5.2. Inherited Security Considerations . . . . . . . . . . . . 7 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 6.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 65 1. Introduction 67 One of the many checks that mail servers carry out is to query DNS 68 whitelists (DNSWL, [RFC5782]). The lookup is based on the connecting 69 client's IP address, so this check can occur very early in an SMTP 70 transaction. The result can be used to counterweight policies that 71 typically occur at early stages too, such as the Sender Policy 72 Framework (SPF, the last paragraph of Appendix D.3 of [RFC7208] is 73 illustrated in Appendix A). In addition, the result of a DNSWL 74 lookup can also be used at later stages; for example, a delivery 75 agent can use it to learn the trustworthiness of a mail relay in 76 order to estimate the spamminess of an email message. The latter 77 possibility needs a place to collect query results for downstream 78 use, which is precisely what the Authentication-Results header field 79 aims at providing. 81 Results often contain additional data, encoded according to DNSWL- 82 specific criteria. The present method considers only whitelists 83 --one of the major branches considered by [RFC5782]. In case of 84 DNSxL, the boundary MTA (see [RFC5598]) which carries out the check 85 and possibly stores the result, has to be able to discern at least 86 the color of "x", which is required to make accept/reject decisions. 87 The present method can then be used only if the DNSxL record to be 88 reported turns out to be a whitelisting one. 90 Data conveyed in A and TXT records can be stored as method's 91 properties. In effect, they are tantamount to local policies, albeit 92 outsourced. Downstream agents need to know DNSWL-specific encoding 93 to understand the meaning of that data. In order to smooth 94 operations, this document endorses a usage of TXT fields consistent 95 with other authentication methods. Namely, to serve the domain name 96 in the TXT record. 98 2. Method Details 100 The following ptype.property items define how the data provided by 101 the whitelist lookup can be saved. 103 dns.zone: DNSWL query root domain, which defines the meaning of the 104 policy.ip property below. Note that an MTA can use a 105 local mirror with a different name. The name stored here 106 has to be the best available reference for all 107 foreseeable downstream consumers. If the message is 108 handed outside the internal network, dns.zone had better 109 be the global zone. 110 policy.ip: The bit mask value received in type A response, in dotted 111 quad. Multiple entries can be arranged in a comma- 112 separated list. 113 policy.txt: The TXT record, if any. Multiple records are 114 concatenated in the usual way (explained, for example, in 115 Section 3.3 of [RFC7208]). See Section 3 for the 116 resulting content and query options. 117 dns.sec: This is a generic property stating whether the relevant 118 data was validated using DNSSEC ([RFC4033]). For the 119 present method, the relevant data consists of the 120 reported policy properties above, or, if the method 121 result is "none", their non-existence. This property has 122 three possible values: 124 yes: DNSSEC validation confirms the integrity of data. 125 Section 5.1 considers how that is related to the DNS 126 response. 127 no: The data is not signed. See Section 5.1. 128 na: Not applicable. No DNSSEC validation can be 129 performed, possibly because the lookup is run 130 through a different means than a security-aware DNS 131 resolver. This does not necessarily imply less 132 security. In particular, "na" is used if the data 133 was downloaded in bulk and then loaded on a local 134 nameserver --which is the case of an MTA querying a 135 local zone different from the reported dns.zone. 136 DNS errors, including validation errors, can also 137 report "na". This is also the value assumed by 138 default. 140 The result of the method states how the query did, up to the 141 interpretation of the result. In particular, some DNSBLs are known 142 to return special codes to signal over quota, for example 143 127.0.0.255. If the MTA cannot interpret that value, that case 144 results in a false positive. 146 The method has four possible results: 148 pass: The query successfully returned applicable records. This 149 result is usually accompanied by one or both the policy 150 properties described above. Agents unable to interpret 151 those properties can still derive a positive value from 152 the fact that the sender is whitelisted. 153 none: The query worked but yielded no A record, or returned 154 NXDOMAIN, so the sender is not whitelisted. 155 temperror: The DNS evaluation could not be completed due to some 156 error that is likely transient in nature, such as a 157 temporary DNS error, e.g., a DNS RCODE of 2, commonly 158 known as SERVFAIL, or other error condition resulted. A 159 later attempt may produce a final result. 160 permerror: The DNS evaluation cannot work because test entries don't 161 work, that is, DNSWL is broken, or because queries are 162 overquota, e.g., a DNS RCODE of 5, commonly known as 163 REFUSED, or a DNSWL-specific policy.ip was returned. A 164 later attempt is unlikely to produce a final result. 165 Human intervention is required. 167 Note that there is no fail result. 169 3. TXT Record Contents 171 According to [RFC5782], TXT records describe the reason why IP 172 addresses are listed in a DNSWL. The TXT record is useful if it 173 contains the domain name(s). The domain name would correspond to the 174 DNS domain name used by or within the ADMD operating the relevant 175 MTA, sometimes called the "organizational domain". In that case, the 176 authentication provided by this method is equivalent to a DKIM 177 signature ([RFC6376]) or an SPF check host ([RFC7208]). 179 According to a DNSWL's policy, attributing responsibility of an IP 180 address to an organization may require something more than a mere PTR 181 record consistency. If no domain names can be responsibly associated 182 to a given IP, for example because the IP was added without direct 183 involvement of the organization concerned, DNSWLs can use a subdomain 184 of .INVALID ([RFC2606]) where the leftmost label hints at why an 185 address is whitelisted. For example, if the address 192.0.2.38 was 186 added by the list managers solely based on their knowledge, the 187 corresponding TXT record might be AUTOPROMOTED.INVALID, so as to 188 avoid to explicitly identify an entity who didn't opt-in. 190 Following the example of Multicast DNS (see the second paragraph of 191 Section 16 of [RFC6762]) names containing non-ASCII characters can be 192 encoded in UTF-8 [RFC3629] using the normalization form canonical 193 composition (NFC) as described in Unicode Format for Network 194 Interchange ([RFC5198]). Inclusion of unaltered UTF-8 TXT values in 195 the header entails an environment compatible with EAI [RFC6530]. 197 DNS queries with a QTYPE of ANY may lead to inconsistent replies, 198 depending on the cache status. In addition, ANY is not "all", and 199 the provisions for queries that have QTYPE=ANY ([RFC8482]) don't 200 cover DNSxLs. A mail server can issue two simultaneous queries, A 201 and TXT. Otherwise, a downstream filter can issue a TXT query on its 202 own, if it knows that an A query was successful and that the DNSWL 203 serves useful TXT records. It is unlikely that TXT records exist if 204 a query for QTYPE A brought a result of none. 206 4. IANA Considerations 208 There is a registry of Email Authentication Methods. The method 209 described in this document is referred by Table 1, along with its 210 ptype.property values. 212 +--------+--------+----------+-------------------+--------+---------+ 213 | Method | ptype | property | Value | Status | Version | 214 +--------+--------+----------+-------------------+--------+---------+ 215 | dnswl | dns | zone | DNSWL publicly | active | 1 | 216 | | | | accessible query | | | 217 | | | | root domain | | | 218 | dnswl | policy | ip | type A response | active | 1 | 219 | | | | received (or | | | 220 | | | | comma-separated | | | 221 | | | | list thereof) | | | 222 | dnswl | policy | txt | type TXT query | active | 1 | 223 | | | | response | | | 224 | dnswl | dns | sec | one of "yes" for | active | 1 | 225 | | | | DNSSEC | | | 226 | | | | authenticated | | | 227 | | | | data, "no" for | | | 228 | | | | not signed, or | | | 229 | | | | "na" for not | | | 230 | | | | applicable | | | 231 +--------+--------+----------+-------------------+--------+---------+ 233 Table 1: Email Authentication Method 235 A new ptype, "dns" is introduced in Table 2. It is meant to be used 236 for properties related to the Domain Name System (DNS [RFC1034]). 238 +-------+------------+----------------------------------------------+ 239 | ptype | Definition | Description | 240 +-------+------------+----------------------------------------------+ 241 | dns | [this doc] | The property being reported belongs to the | 242 | | | Domain Name System | 243 +-------+------------+----------------------------------------------+ 245 Table 2: Email Authentication Property Type 247 This method reuses four of the values already defined in the Email 248 Authentication Result Names associated registry. They are listed in 249 Table 3. 251 +---------+-----------+------------------------------------+--------+ 252 | Auth | Code | Specification | Status | 253 | Method | | | | 254 +---------+-----------+------------------------------------+--------+ 255 | dnswl | pass | Sender is whitelisted, up to | active | 256 | | | returned code interpretation | | 257 | dnswl | none | NXDOMAIN or no record, sender is | active | 258 | | | not whitelisted | | 259 | dnswl | temperror | Transient DNS error during the | active | 260 | | | query | | 261 | dnswl | permerror | Query cannot work, human | active | 262 | | | intervention needed | | 263 +---------+-----------+------------------------------------+--------+ 265 Table 3: Email Authentication Result Names 267 5. Security Considerations 269 5.1. Security of DNSSEC Validation 271 The dns.sec property is meant to be as secure as DNSSEC results. It 272 makes sense to use it in an environment where the DNSSEC validation 273 can succeed. 275 Section 7 of [RFC4033] examines various ways of setting up a stub 276 resolver which either validates DNSSEC locally or trusts the 277 validation provided through a secure channel. For a different class, 278 it is possible to set up a dedicated, caching, dnssec-enabled 279 resolver reachable by the mail server through interprocess 280 communication on 127.0.0.1. In such cases, the property dns.sec=yes 281 corresponds to the Authenticated Data (AD) bit in the DNS response 282 header. 284 When the response contains no DNSSEC data, a security-aware resolver 285 seeks a signed proof of the non-existence of a DS record, at some 286 delegation point. If no error is returned, the zone is unsigned and 287 dns.sec=no can be set. Quoting the Security Considerations 288 Section of [RFC3225]: The absence of DNSSEC data in response to a 289 query with the DO bit set MUST NOT be taken to mean no security 290 information is available for that zone as the response may be forged 291 or a non-forged response of an altered (DO bit cleared) query. 293 If the application verifies the DNSSEC signatures on its own, it 294 effectively behaves like a validating stub resolver, and hence can 295 set dns.sec correspondingly. 297 When the data is downloaded in bulk and made available on a trusted 298 channel without using DNSSEC, set dns.sec=na or not at all. DNSWL 299 who publish bulk versions of their data can also sign that data, for 300 example using OpenPGP ([RFC4880]). It is the responsibility of 301 system administrators to authenticate the data by downloading and 302 validating the signature. The result of such validation is not 303 reported using dns.sec. 305 5.2. Inherited Security Considerations 307 For DNSSEC, the considerations of Section 12 of [RFC4033] apply. 309 All of the considerations described in Section 7 of [RFC8601] apply. 310 That includes securing against tampering all the channels after the 311 production of this Authentication-Results header field. 313 In addition, the usual caveats apply about importing text from 314 external online sources. Although queried DNSWLs are well known, 315 trusted entities, it is suggested that TXT records be reported only 316 if, upon inspection, their content is deemed actually actionable, and 317 their format compatible with the computing environment. 319 6. References 321 6.1. Normative References 323 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 324 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 325 . 327 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 328 DOI 10.17487/RFC5782, February 2010, . 331 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 332 Message Authentication Status", RFC 8601, 333 DOI 10.17487/RFC8601, May 2019, . 336 6.2. Informative References 338 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 339 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 340 . 342 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 343 RFC 3225, DOI 10.17487/RFC3225, December 2001, 344 . 346 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 347 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 348 2003, . 350 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 351 Rose, "DNS Security Introduction and Requirements", 352 RFC 4033, DOI 10.17487/RFC4033, March 2005, 353 . 355 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 356 Thayer, "OpenPGP Message Format", RFC 4880, 357 DOI 10.17487/RFC4880, November 2007, . 360 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 361 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 362 . 364 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 365 DOI 10.17487/RFC5598, July 2009, . 368 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 369 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 370 RFC 6376, DOI 10.17487/RFC6376, September 2011, 371 . 373 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 374 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 375 February 2012, . 377 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 378 DOI 10.17487/RFC6762, February 2013, . 381 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 382 Authorizing Use of Domains in Email, Version 1", RFC 7208, 383 DOI 10.17487/RFC7208, April 2014, . 386 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, 387 "Providing Minimal-Sized Responses to DNS Queries That 388 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 389 2019, . 391 Appendix A. Example 393 Delivered-To: recipient@example.org 394 Return-Path: 395 Authentication-Results: mta.example.org; 396 dkim=pass (whitelisted) header.i=@example.com 397 Authentication-Results: mta.example.org; 398 dnswl=pass dns.zone=list.dnswl.example dns.sec=na 399 policy.ip=127.0.10.1 400 policy.txt="fwd.example https://dnswl.example/?d=fwd.example" 401 Received-SPF: fail (Address does not pass Sender Policy Framework) 402 client-ip=192.0.2.1; 403 envelope-from="sender@example.com"; 404 helo=mailout.fwd.example; 405 receiver=mta.example.org; 406 Received: from mailout.fwd.example (mailout.fwd.example [192.0.2.1]) 407 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256) 408 by mta.example.org with ESMTPS; Thu, 03 Ocy 2019 19:23:11 +0200 409 id 00000000005DC044.000000005702D87C.000007FC 411 Trace fields added at the top of the header by multiple agents at 412 various stages during processing at the final MTA 414 The message went through a third party, fwd.example, which forwarded 415 it to the final MTA. Such mail path was not arranged beforehand with 416 the involved MTAs, it emerged spontaneously. This message would not 417 have made it to the target without whitelisting, because: 419 o the author domain published a strict SPF policy (-all), 420 o the forwarder did not alter the bounce address, and 421 o the target usually honors reject-on-fail, according to Section 8.4 422 of [RFC7208]. 424 However, the target also implemented the last paragraph of 425 Appendix D.3 of [RFC7208]. Rather than rejecting the message 426 outright before DATA, the MTA received it, recorded the SPF fail 427 result, and indicated the local policy mechanism which was applied in 428 order to override that result. Subsequent filtering detected no 429 malware and verified DKIM [RFC6376]. It would still have been 430 possible to reject the message, based on its content. It is at these 431 later stages, after receiving the body and also during delivery, that 432 a deeper knowledge of the policy values obtained from dnswl.example 433 can allow weighting that score against other factors. 435 Author's Address 437 Alessandro Vesely 438 v. L. Anelli 13 439 Milano, MI 20122 440 IT 442 Email: vesely@tana.it