idnits 2.17.1 draft-otis-tpa-label-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1563 has weird spacing: '... int ret_v...' == Line 1643 has weird spacing: '... else if (c...' -- The document date (June 26, 2014) is 3585 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 607, but not defined == Missing Reference: 'ANY' is mentioned on line 738, but not defined -- Looks like a reference, but probably isn't: '20' on line 1569 -- Looks like a reference, but probably isn't: '33' on line 1569 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7001 (Obsoleted by RFC 7601) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-10 == Outdated reference: A later version (-02) exists of draft-kucherawy-dkim-delegate-01 == Outdated reference: A later version (-13) exists of draft-kucherawy-dmarc-base-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Appsawg D. Otis 3 Internet-Draft Trend Micro 4 Intended status: Experimental D. Black 5 Expires: December 28, 2014 June 26, 2014 7 Third-Party Authorization Label 8 draft-otis-tpa-label-04 10 Abstract 12 This experimental specification proposes a Third-Party Authorization 13 Label (TPA-Label) as a DNS-based method that allows Trusted Domains 14 an efficient means to authorize acceptable Third-Party Domains. This 15 method permits autonomous unilateral authorizations and uses scalable 16 individual DNS transactions. 18 A TPA-Label Resource Record transaction asserts an alignment 19 exception to convey informally Federated Domains. It affords 20 recipients a practical and safe means to extend Domain Alignment. 21 Exceptions are managed by either the Trusted Domain, or their agent, 22 seeking to avoid disruption of informal services enjoyed by their 23 users. Third-Party Authorization of a Federated Domain eliminates a 24 need to share private credentials. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 28, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Domain Validation Issues . . . . . . . . . . . . . . . . . . . 6 69 4. Incomplete Assertions Not Congruent with SMTP . . . . . . . . 7 70 5. Why DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. TPA-Label Listed Domain, TPA-LLD, . . . . . . . . . . . . . . 8 72 7. TPA-Label Resource Record Authorization Considerations . . . . 9 73 8. Evaluating the Third-Party Domain . . . . . . . . . . . . . . 10 74 8.1. Third Party Authorization - Closed Mailing List Example . 11 75 8.2. Third Party Authorization - Open Mailing List Example . . 11 76 8.3. Third Party Authorization Example - Sender Header Field . 11 77 8.4. Services Lacking DKIM Signatures . . . . . . . . . . . . . 12 78 8.4.1. Abuse and DSN Reporting . . . . . . . . . . . . . . . 12 79 8.4.2. Third Party Authorization Example - SMTP Host . . . . 12 80 8.4.3. Third Party Authorization Example - Return Path . . . 12 81 8.4.4. Use of Path Authorization . . . . . . . . . . . . . . 12 82 9. DNS Representation . . . . . . . . . . . . . . . . . . . . . . 13 83 10. TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . . 13 84 11. TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 14 85 12. TPA-Label TXT Resource Record Structure . . . . . . . . . . . 15 86 13. TPA-Label Resource Record Definition . . . . . . . . . . . . . 16 87 14. TPA-Label Resource Record Version . . . . . . . . . . . . . . 16 88 15. Authorized Validated Domains . . . . . . . . . . . . . . . . . 16 89 15.1. TPA-Label Resource Record Param Syntax . . . . . . . . . . 17 90 15.2. Header Dependent Authorizations . . . . . . . . . . . . . 17 91 15.2.1. List-ID Header Field . . . . . . . . . . . . . . . . . 17 92 15.2.2. Sender Header Field . . . . . . . . . . . . . . . . . 18 93 15.2.3. OAR Header Field . . . . . . . . . . . . . . . . . . . 18 94 15.2.4. Combined 'L' or 'S' Params . . . . . . . . . . . . . . 18 95 15.3. DKIM signed domain . . . . . . . . . . . . . . . . . . . . 18 96 15.3.1. DKIM signed . . . . . . . . . . . . . . . . . . . . . 18 97 15.4. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 18 98 15.5. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 18 99 15.6. MailFrom Parameter . . . . . . . . . . . . . . . . . . . . 18 100 15.7. Not Federated . . . . . . . . . . . . . . . . . . . . . . 19 101 15.8. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 102 16. TPA-Label Resource Record Query Transactions . . . . . . . . . 19 103 17. TPA-Label Resource Record Compliance Extension . . . . . . . . 20 104 18. Alternative Mitigation Strategies . . . . . . . . . . . . . . 21 105 18.1. Proposed DKIM-Delegate Signature survives all Message 106 modifications . . . . . . . . . . . . . . . . . . . . . . 21 107 18.2. Vouch-By-Reference . . . . . . . . . . . . . . . . . . . . 22 108 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 22 109 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 110 20.1. Moving RFC6541 to historic . . . . . . . . . . . . . . . . 23 111 20.2. TPA-Label (TPA-LLD) Parameters . . . . . . . . . . . . . . 23 112 20.3. Email Authentication Method Registry . . . . . . . . . . . 24 113 20.4. Email Authentication Result Names Registry . . . . . . . . 24 114 20.5. Third Party Authorizations Labels Registry . . . . . . . . 25 115 20.6. Third Party Authorizations Param Registry . . . . . . . . 25 116 21. Security Considerations . . . . . . . . . . . . . . . . . . . 26 117 21.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 26 118 21.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 27 119 21.3. Benefits to Trusted Domains . . . . . . . . . . . . . . . 27 120 21.4. Risks to Trusted Domains . . . . . . . . . . . . . . . . . 28 121 21.5. Benefits to Third Party Signers . . . . . . . . . . . . . 29 122 21.6. Risks caused by Third Party Signers . . . . . . . . . . . 29 123 21.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 29 124 21.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 29 125 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 126 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 127 23.1. Normative References . . . . . . . . . . . . . . . . . . . 30 128 23.2. Informative References . . . . . . . . . . . . . . . . . . 31 129 Appendix A. DNS Example of TPA-Label Resource Record placement . 33 130 Appendix B. C code for label generation . . . . . . . . . . . . . 34 131 Appendix C. History of Prior Efforts . . . . . . . . . . . . . . 39 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 134 1. Introduction 136 A TPA-Label Resource Record supports an authorization of separately 137 validated domains. This added authorization step avoids a need to 138 share private credentials. Also, it ensures each domain remains 139 apparent and open to validation when establishing an informal 140 federation of domains protecting Federated Domain Identities. To 141 improve security, authorization records may also limit how they are 142 to be applied. 144 With TPA-Label Resource Records, mailing lists, among similar Third- 145 Party Domain services, can indirectly assert protection of identities 146 when the source domain is within an informally Federated Domain. 147 Since mailing-lists receive differently formatted messages, a common 148 practice is to convert multi-party conversations into consistent and 149 compact formats facilitating the organization of the many multi-party 150 conversations. Such processing often breaks any meaningful message 151 signature. With the proposed scheme, trusting the federated message 152 source can supersede otherwise broken alignment validation. 154 Trusted Domains can seek to ensure the domains they federate protect 155 the Federated Identity. In situations where the Trusted Domain 156 cannot be confirmed, TPA-Labels are able to signal which domains are 157 within the Trusted Domain's informally established federation. When 158 a user wishes to utilize an informal Third-Party Domain service, it 159 is both logical and desirable to retain the original Federated 160 Identity to better convey who substantially created message content. 161 Not retaining this identity would otherwise prohibit subsequent 162 review of prior exchanges. However, when recipients wish to 163 determine whether to trust the Federated Identity, Domain Alignment 164 with the validated source may not exist. TPA-Labels can indicate 165 whether the source domain has been informally federated by the 166 Trusted Domain. 168 2. Terminology 170 Please see [RFC5598] for general email terminology. 172 The following additional terms are used: 174 Transparent Domain Authorization: Third-Party Domains validating as 175 the Trusted Domain represent a type of transparent authorization. 176 This method normally depends on securely sharing private details 177 between domain owners and providers. However, private sharing 178 between different administrative domains is expensive and carries 179 some risk a security breach may result in the wrong administration 180 being held accountable or more resources being placed in peril. 182 Trusted Domain: Often a visible domain that acts as a basis for 183 acceptance and/or subsequent actions. For DMARC, this is the 184 fully qualified domain name found in the From header field. 186 Author Domain: See Section 3 of DMARC ([I-D.kucherawy-dmarc-base] 187 specifying the domain of the From header field which represents 188 the Trusted Domain. 190 Federated Domain: A domain (among possibly others) working in 191 concert with the Trusted Domain authorized as protecting Federated 192 Identifiers. 194 Federated Identity: Identity protected by a Federated Domain. In 195 the case of DMARC, this identity is contained in the From header 196 field. 198 Domain Alignment: Strict alignment requires matching the Trusted 199 Domain. Relaxed alignment allows source domains to be a sub- 200 domain of the Trusted Domain. 202 Third-Party Authorization: A different domain authorized by the 203 Trusted Domain. 205 Informal Third-Party Service: A Service not by the Trusted Domain 206 that does not require administrative cooperation for users to 207 independently establish their own access credentials. 209 Third-Party Service: A Service not by the Trusted Domain. 211 Third-Party Domain: A domain that is not the Trusted Domain. 213 TPA-Label Authorization: The referencing domain which meets the 214 validation and header field content requirements of the resolved 215 TPA-Label Resource Record is thereby authorized by the Trusted 216 Domain. 218 TPA-Label Listed Domain, TPA-LLD: TPA-Label Listed Domain, TPA-LLD, 219 is a TXT Resource Record referenced with the hash value of the 220 domain being authorized. This Resource Record is published within 221 a Trusted Domain. When a "tpa" tag exists, the referencing domain 222 (the domain used to generate the label) must be within the listed 223 domains. When the "tpa" tag does not exist, the referenced domain 224 is presumed. The "param" tag may stipulate a required existence 225 of additional header fields, or indicate alternate domain 226 validation methods to be applied against specific elements. The 227 "param" tag may also indicate that the domain matching in the 228 prior "tpa" list validated according to "param" associated listed 229 methods, is specifically not federated by the Trusted Domain. 231 3. Domain Validation Issues 233 Changing the validated domain, the one referenced by SPF [RFC7208], 234 or the one adding a DKIM [RFC6376] signature, is not a problem since 235 it is rare for acceptance to be based on From header field Domain 236 Alignment. However, when acceptance is based on the From header 237 field alignment, as in the case of DMARC [I-D.kucherawy-dmarc-base] 238 using either SPF or DKIM, this can disrupt many Third-Party Services. 239 The disruption becomes egregious when messages from the domain's own 240 users are rejected based on the level of this domain's asserted 241 alignment practices. At the strictest alignment level, an erroneous 242 assertion not only disrupts messages from their users, it can also 243 affect subscriptions or services for other users of the Third-Party 244 Service. 246 DKIM, unlike SPF, permits better retention of From/signature 247 alignment where only the From header field could be signed. 248 Nevertheless, the integrity of the original DKIM signature is likely 249 affected by message flattening, inclusion of Subject tags, or 250 appended list footer information. Just signing the From header field 251 is not a practical solution, because it would expose this message 252 fragment to replay abuse, even when given short signature expiry. 254 TPA-Label authorization may individually authorize domain validation 255 methods. This may either increase or decrease the number of 256 validation methods normally used. For example, a virtual server may 257 share an IP address with thousands of different domains. Its 258 authorization may need to exclude IP addresses as a basis for 259 validation. In the TPA-Label scheme, unless a validation method is 260 asserted, no changes to the domain validation process should be 261 assumed. 263 TPA-Labels can minimize the number of systems involved and the 264 related deployment time before the disruption of legitimate messaging 265 is avoided. TPA-Labels should also ensure greater cooperation to 266 sustain the desired protections. These types of restrictions are 267 increasingly likely to be relied upon to help mitigate harm caused by 268 future breaches. 270 4. Incomplete Assertions Not Congruent with SMTP 272 A few large domains have had a high percentage of user accounts 273 compromised. These events have given malefactors access to prior 274 private exchanges and contact lists. Even after accounts had been 275 reclaimed, malefactors continue sending convincing spoofed messages 276 from other sources. To mitigate harm, some domains have asserted 277 Domain Alignment practices similar to those used by domains that only 278 emit transactional messaging where a recommendation is normally 279 heeded. In addition, some domains also recommended "reject" rather 280 than "quarantine" as a misalignment response. In conjunction with 281 misleading alignment assertions, rejection becomes a highly 282 disruptive choice. 284 It is unfair to place a burden on receivers and expect them to be 285 cooperative. Trusted Domains have access to information that 286 receivers do not. This information is necessary to prevent the 287 disruption of otherwise legitimate messages from their users, and it 288 can be passed on to receivers using TPA-Labels. Prior to making 289 alignment assertions that are likely to disrupt services carrying 290 legitimate messages, Trusted Domains should publish TPA-Labels that 291 list their compilation of Third-Party Domains federated as conveying 292 their users' messages without modifying the Federated Identity. When 293 Trusted Domains proactively guard against disruption of legitimate 294 messages, receivers are then more likely to cooperate with their 295 recommendations. 297 5. Why DMARC 299 Deterrents based upon reputation and/or path based scoring strategies 300 that utilize a variety of originating header fields has proved 301 ineffective. The header fields often remain invisible to recipients, 302 and contain domains exploited for periods measured in hours, to avoid 303 any Whack-A-Mole like response. Even long term reputations have 304 issues due to an intermix of messages from compromised accounts. 305 Content filtering is unable to keep up with the polymorphic abuse. 306 Few recipients will inspect the stack of message header fields, or be 307 able to draw useful conclusions from a profusion of unfriendly 308 information. As a result, many recipients deal with abuse by sorting 309 messages into groups based on assumed sources found in a few 310 originating header fields. 312 DMARC represents an open registry that offers domain specific 313 guidance for DKIM/SPF alignment sending practices to determine 314 whether messages should be delivered, quarantined, or refused. 315 However, appropriate actions become unclear whenever Third-Party 316 Services are involved. Although DMARC warns of a potential for 317 disruption, the specific handling requested by DMARC is very limited. 318 DMARC expects receivers to devise their own special handling to 319 mitigate disruptions that DMARC assertions might cause for legitimate 320 messaging. This is unfortunate, since the necessary feedback is 321 given to the Trusted Domain and not to the cooperating receivers. 322 TPA-Labels can ensure recipients are provided this necessary 323 information. 325 Administrative domains, that assert all of their outbound message 326 sources can be validated as having aligned domains, offer significant 327 forensic value. However, messages where domains are not in alignment 328 remain a potential issue. Only domains offering messages of a 329 transactional nature are unlikely to benefit from the use of TPA- 330 Labels. 332 This document describes how any Trusted Domain publishing DMARC 333 records can autonomously authorize other validated domains. TPA- 334 Labels offer secondary compliance options whenever authorized 335 exceptions are needed to permit the use of Third-Party Domains. The 336 intended purpose of TPA-Label Resource Records is to improve 337 acceptance rates of genuine messages, to minimize DNS use, to 338 minimize success rates for phishing, to improve sorting protections, 339 and to minimize a recipient's administrative costs. 341 TPA-Label Resource Records authorize Third-Party Domains and services 342 to extend compliance options for asserted practices defined by 343 [I-D.kucherawy-dmarc-base]. Domains, that both reference and are 344 listed, and also comply with a TPA-Label resource record, should be 345 considered equivalent to the authorizing Trusted Domain when 346 assessing compliance with DMARC asserted practices. 348 6. TPA-Label Listed Domain, TPA-LLD, 350 TPA-Label Listed Domain, TPA-LLD, is a TXT resource record referenced 351 with a TPA-Label published within a Trusted Domain. When a "tpa" tag 352 exists within the TXT resource record located at the TPA-Label, the 353 referencing domain (the domain used to generate the label) must be 354 within the listed domain. When the "tpa" tag does not exist, the 355 referenced domain is presumed listed. The "param" tag may stipulate 356 existence of additional header fields, or indicate alternate 357 validation methods applied against specific email elements. 359 Third-Party Domain validation might use a DKIM signature or confirm 360 the Authorized Domain using specific methods with various path 361 related email elements. The default assertion for param is 'd' and 362 'm', indicating DKIM or the Mail From parameter processed by SPF 363 confirms the Authorized Domain when no other method is specified. 364 The 'S' and 'L' param do not confirm the domain, but requires at 365 least one Sender or List-ID header field to hold a TPA-LLD 366 respectively. The 'O' param can be stipulated when the Authorized 367 Domain does not offer DMARC acceptance or validate access in 368 association with From header fields. The 'e', 'h', and 't' indicate 369 specific alternative methods using message elements to confirm the 370 Authorized Domain. 372 When any param method is asserted (denoted by a lower case letter), 373 methods not listed should not be considered to provide valid results. 374 The 'n' assertion indicates that the prior domain listed in the same 375 TPA-LLD is specifically not federated as determined by either the 376 default or listed methods. Being compliant with TPA-LLD allows the 377 referencing domain to informally act on behalf of the Trusted Domain. 378 Indicating domains as not federated necessitates the use of sequence 379 sensitive "tpa" and "param" pairs within the TPA-LLD. Per [RFC5321], 380 domain name comparisons, as well as TPA-Labels, are case insensitive. 382 7. TPA-Label Resource Record Authorization Considerations 384 When a Trusted Domain is not within a DKIM or SPF validated domain, 385 the TPA-LLD scheme can extend Domain Alignment compliance. The TPA- 386 LLD scheme with an 'S', or 'L' param requires the respective Sender 387 header field or a List-ID identifier of the List-ID header field to 388 exist for at least one of the params, and to contain a domain within 389 the TPA-LLD for authorization to be valid. The 'd' param permits 390 validations based upon the DKIM signing domain. The 'm' param 391 permits validations based upon the return path (Mail From) domain. 392 The 'e', 'h', and 't' params permit acceptance based upon validation 393 of the client hostname (EHLO/HELO). 395 The 'S' and 'L' params support message sorting. Any matching header 396 field with a domain within the TPA-LLD allows recipients to 397 differentiate sources, which satisfies requirements for any other 'S' 398 or 'L' param. The 'S' and 'L' params provide Trusted Domains a means 399 to limit domain authorizations. 401 The TPA-LLD scheme plays the role of only qualifying acceptable 402 domains with the goal of improving delivery acceptance, such as 403 messages from specific mailing-lists. The TPA-LLD authorization 404 scheme only requires that DNS publications be made by the Trusted 405 Domain, even when the sending domains and the Trusted Domain differ. 407 This approach eliminates a need to exchange private information thus 408 protecting the domain's integrity. Before TPA-LLD authorization is 409 deployed, the Trusted Domain should be assured by domains being 410 authorized that appropriate measures are in place to validate those 411 submitting messages and ensure the Federated Identity is protected. 413 Retaining validation and authorization for the From, Sender, and 414 List-ID header fields, and being able to ensure Third-party inclusion 415 of a Sender or List-ID header fields, enhances protections afforded 416 by message sorting. This protection reduces susceptibility to 417 deceptive look-alike phishing attempts. Use of subdomains that 418 assert less stringent practices might inadvertently combine with 419 those having more stringent practices when sorting is based upon 420 parent domains. Consistently using the same domain prevents possible 421 confusion that could be exploited to deceive recipients. 423 TPA-Label authorization will not ensure all possible spoofing is 424 prevented. However, by permitting broader use of strict alignment 425 practices, this should generally reduce the level of spoofing over 426 what might be otherwise allowed. Authorized third party messages 427 SHOULD NOT receive annotations that indicate the message contains 428 validated identities. The TPA-LLD param SHOULD include the 'S' or 429 'L' param where appropriate to allow recipients a means to isolate 430 and distinguish different message sources. 432 8. Evaluating the Third-Party Domain 434 A Trusted Domain deploying a TPA-Label Resource Record does so on a 435 trust basis. Reasons for deploying TPA-Label Resource Records might 436 be to allow deployment of more stringent DMARC records while also 437 utilizing Third-Party Services. 439 When an authorized Third Party domain does not employ DKIM or SPF or 440 does not include Authentication-Results header fields [RFC7001] or 441 perhaps [I-D.kucherawy-original-authres] (OAR) or its "X-" version 442 could allow authorizations to be exploited. For Third Party domains 443 not applying DMARC but capture the OAR, past compliance with DMARC 444 based on the OAR can be made a requirement for authorization. 446 While conceivably Domain Alignment might just rely on the content of 447 the Original-Authentication-Results header, whether to trust this, or 448 any other message content can not be based on the mere acceptance of 449 the message alone. Whether false content even effects message 450 acceptance would be difficult to determine. Only the Trusted Domain 451 is able to make this type of determination based on their knowledge 452 of outbound messages and corrections needed based on DMARC feedback 453 which they then share in the form of a TPA-Label. 455 8.1. Third Party Authorization - Closed Mailing List Example 457 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 458 mailing list with a closed posting policy. The mailing list 459 redistributes email which breaks the Trusted Domain Alignment, and 460 the mailing list offers a means to validate the mailing list domain 461 and includes an Authentication-Results header field for posted 462 messages. The closed posting policy can be enforced by requiring 463 subscribers to validate control of their Author Addresses by 464 responding to encoded "pingback" email sent to these addresses. 466 Since the mailing list validates their domain as indicated in the 467 TPA-Label, and validates control of the posted message Author 468 Address, and includes Authentication-Results header fields, and 469 includes a List-ID header field, the referenced TPA-Label Resource 470 Record can include an 'L' param value to stipulate that the Third- 471 Party Domain messages contain an authorized List-ID domain. 473 8.2. Third Party Authorization - Open Mailing List Example 475 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 476 mailing list with an open posting policy. The mailing list 477 redistributes email in a way that breaks Trusted Domain alignment, 478 does not post from an Author Address not in compliance with DMARC, 479 offers a means to validate the mailing list domain, and it includes 480 an Authentication-Results header field for posted messages. 482 Since the mailing list validates the domain as indicated in the TPA- 483 Label, and is configured to include Authentication-Results header 484 fields and possibly the Original-Authentication-Results 485 [I-D.kucherawy-original-authres], and includes a List-ID header 486 field, the referenced TPA-Label Resource Record can include an 'L' 487 param value to stipulate the Third-Party Domain messages contain an 488 authorized List-ID domain. 490 8.3. Third Party Authorization Example - Sender Header Field 492 Trusted Domain "example.com" wishes to temporarily employ the service 493 agency "temp.example.org" to handle overflow secretarial support. 494 The agency "temp.example.org" sends email on behalf of the executive 495 staff of "example.com" and adds the Sender header field of 496 "secretary@temp.example.org" in the email. 498 Since "temp.example.org" only allows its own staff to email through 499 its server which adds "temp.example.org" DKIM signatures, a TPA-LLD 500 can include the "temp.example.org" domain with an 'S' and 'd' param 501 to specifically authorize DKIM signed messages containing the Sender 502 header field, to help ensure these messages are not handled as 503 phishing attempts. 505 8.4. Services Lacking DKIM Signatures 507 8.4.1. Abuse and DSN Reporting 509 There is likely little interest for an otherwise uninvolved domain to 510 receive a massive number of bogus messages being returned as 511 feedback. Often the purpose of feedback is to discover compromised 512 systems or accounts actively being exploited in some manner. Unless 513 the Trusted Domain is confirmed as having handled or authorized the 514 handling of the message, only statistics and samples should be 515 reported to the associated Autonomous System [RFC1930], and perhaps 516 to the Trusted Domain when interest is expressed. 518 The 'd', 'e', 'h', 'm', and 't' param options within the TPA-LLD 519 records allow the Trusted Domain to be associated through various 520 methods. In this case, appropriate DSN or abuse reporting to the 521 Trusted Domain is better assured as well. 523 8.4.2. Third Party Authorization Example - SMTP Host 525 Trusted Domain "example.com" makes use of invite services. This 526 service does not utilize DKIM, where the host name given by the EHLO 527 command is "invite.example.net". The Trusted Domain can authorize 528 the domain "invite.example.net" or "example.net" with the param of 529 'e' to improve acceptance of messages that are sent on behalf of 530 "example.com" from this outbound server. 532 8.4.3. Third Party Authorization Example - Return Path 534 Trusted Domain "example.com" makes use of tell-a-friend services. 535 This service does not utilize DKIM with its own return path as 536 "customer@taf.example.net" in the SMTP exchange. The Trusted Domain 537 can authorize the domain "taf.example.net" with the param of 'm' to 538 improve acceptance of messages that are sent on behalf of 539 "example.com" from this outbound server. 541 8.4.4. Use of Path Authorization 543 Those using validations related to 'e', 'h', 'm' param options should 544 not authorize domains requiring more than an average number of 545 network transactions. Those implementing DMARC should also limit the 546 number of DNS transactions attempted, otherwise this could negatively 547 impact unrelated domains when evaluating path related validation. 549 Methods that create subsequent transactions based upon the macro 550 expansion of email-address local-parts should not be used. 551 Libraries that process SPF [RFC7208] record scripts may invoke a 552 large number of DNS transactions from cached records, and target 553 unrelated domains with queries modulated by the local-part 554 component through receiver macro expansion. 556 9. DNS Representation 558 The receiver obtains domain authorizations with a DNS query for an IN 559 class TXT TPA-Label Resource Record located below the 560 "_smtp._tpa." location. The TPA-Label itself is 561 generated by processing the domain in question, which normally 562 matches the DKIM signature's "d=" parameter. The Trusted Domain 563 provides authorization for other domains with the existence of a TPA- 564 Label TXT resource record. When a "tpa" tag value exists, it MUST 565 include the referenced domain before authorization is valid. This 566 represents an informal authorization on behalf of the Trusted Domain 567 which can be limited by the "param" tag value for specific message 568 elements. 570 A Trusted Domain may wish to delegate the listing of Third-Party 571 Services to a different administrative domain. Ideally, this would 572 be accomplished by delegating the _tpa. zone to the 573 administrative entity handling publication of TPA-Label Resource 574 Records. This delegation could also be done unilaterally with a 575 DNAME [RFC6672] resource record published at _smtp._tpa.. 578 Character-strings contained within the TXT resource record are 579 concatenated into forming a single string. A character-string, as 580 defined in [RFC1035] Section 3.3 for resource records, is a single 581 length octet followed by that number of characters treated as binary 582 information. 584 The TPA-Label Resource Records should be located at these domains: 586 ._smtp._tpa.. 588 10. TPA-Label and Tag Syntax Definitions 590 Augmented BNF for Syntax Specifications: 592 asterisk = %x2A ; "*" 593 dash = %x2D ; "-" 594 dot = %x2E ; "." 595 underscore = %x5F ; "_" 596 ANY = asterisk dot ; "*." 597 dns-char = ALPHA / DIGIT / dash 598 id-prefix = ALPHA / DIGIT 599 label = id-prefix [*61dns-char id-prefix] 600 sldn = label dot label 601 base-char = (dns-char / underscore) 602 domain = *(label dot) sldn 604 FWS = ([*WSP CRLF] 1*WSP) ; omits RFC5322 obs-FWS 605 tag-sep = %x3B ; "%" 606 tag-list = tag-spec 0*( tag-sep tag-spec ) [ tag-sep ] 607 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 608 tag-name = ALPHA 0*ALNUMPUNC / "v" / [["tpa"] / ["param"]] 609 tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] 610 ; WSP and FWS prohibited at beginning and end 611 tval = 1*VALCHAR 612 VALCHAR = %x21-3A / %x3C-7E 613 ; EXCLAMATION to TILDE except SEMICOLON 614 ALNUMPUNC = ALPHA / DIGIT / "_" 616 11. TPA-Label Generation 618 The TPA-Label is generated by nesting functions as follows: 620 "base32" function is defined in [RFC4648]. 622 "sha1" function is defined in [FIPS.180-2.2002]. 624 "lcase" converts upper-case ALPHA characters to lower-case. 626 "tpa-domain" is normally the "d=" tag value defined in Section 3.5 627 of [RFC6376]. 629 (underscore) base32( sha1( lcase(tpa-domain))) 631 The TPA-Label is created from the hash value returned by the "sha1" 632 function of the tpa-domain expressed in lower case ASCII. Any 633 terminating period is not included with the tpa-domain, as indicated 634 by the ABNF definition. 636 Note: No newline character, 0x0A, is to be appended to the end of 637 the domain name, as might occur with the command line generation 638 of sha1 values. For example, these command line appended newlines 639 can be avoided by using the 'echo -n" option. 641 The label encoding process inputs the hash as a byte stream of four 642 40-bit data blocks where each data block outputs 8 encoded 643 characters. Proceeding from left to right, a 40-bit input group is 644 formed by concatenating 5 bytes. The 40-bit input is then treated as 645 8 concatenated 5-bit groups, each of which is translated into a 646 single digit of the base32 alphabet. The bit stream is ordered with 647 the most-significant-bit first, being the high-order bit of the first 648 byte. The entire output is then concatenated first to last, left to 649 right, into 32 characters prefixed with an underscore. 651 12. TPA-Label TXT Resource Record Structure 653 Every TPA-Label TXT resource record MUST start with the version tag, 654 so the first six characters of the record are lowercase "v=tpa1", 655 TPA-Label syntax descriptions for additional tags follow the tag- 656 value syntax described in the ABNF below, the WSP token is inherited 657 from [RFC5322]. The ALPHA and DIGIT tokens are imported from 658 [RFC5234]. The "param" values refer only to domains previously 659 listed in the TPA-LLD which makes the "tpa" and "param" tags 660 sensitive to their sequence. 662 The tags used in TPA-Label Resource Records are as follows: 664 +------------+--------------------------------------+ 665 | Tag | Function | 666 +------------+--------------------------------------+ 667 | v | Label Version (version-tag) | 668 | tpa | Authorized Domains List (tpa-tag) | 669 | param | Authorization Param List (param-tag) | 670 +------------+--------------------------------------+ 672 TPA-Label Tags 674 +--------+------------------------------------+---------------------+ 675 | param | Field or Parameter | Method | 676 | values | | | 677 +--------+------------------------------------+---------------------+ 678 | L | List-ID Header Field | Match List-ID | 679 | | | Identifier | 680 | S | Sender Header Field | Match Address | 681 | | | Domain | 682 | O | Original Authentication Results | Match Address | 683 | | Header Field | Domain | 684 | d | DKIM Signature | Match Signature | 685 | | | Domain | 686 | e | SMTP Hostname | Resolve Hostname IP | 687 | | | Addr | 688 | h | SMTP Hostname | Pass SPF with | 689 | | | Hostname | 690 | n | Not Federated | See Other Params | 691 | m | MailFrom | Pass SPF with | 692 | | | MailFrom | 693 | t | SMTP Hostname | Cert of Hostname | 694 +--------+------------------------------------+---------------------+ 696 TPA-Label Param Values 698 13. TPA-Label Resource Record Definition 700 Tags in the TPA-Label Resourse Record are shown below. The ver-tag 701 MUST be present as the left most tag. Unrecognized tags MUST be 702 ignored. 704 TPA-Label Resource Record Definition 705 tpalabelrr = v-tag [tag-sep] 0*( 1*(WSP) tag-list) ] 707 14. TPA-Label Resource Record Version 709 Label Version (Required). This tag defines the version of the TPA- 710 Label. Only recognized tpa:param values offer DMARC authorizations 711 (except for param "n" which excludes domains validated per other 712 param values). 714 "v" tag 715 v-tag = %76.3d.74.70.61.31 ; "v=tpa1" 717 15. Authorized Validated Domains 718 Authorized validated domain list. (optional) This tag, when present, 719 MUST contain a domain that repeats all or right-most portions of the 720 domain encoded within the TPA-Label Resource Record. This option 721 ensures the proper handling of possible hash collisions. When a 722 domain is prefixed with the "*." ANY label, then all subdomains of 723 this domain are to be considered included within the list. When the 724 'tpa' tag is not present or has no value, it should be assumed to 725 compare with the domain used to generate the TPA-Label. The purpose 726 of the ANY label is to reduce the size of the resource records. 727 Containing the entire string to confirm hostnames or List-ID content 728 is unnecessary. The hash label must still be an exact match of the 729 domain authorized. Additional domains may be included as optional 730 Sender or List-ID comparison options. The tpa list is optionally 731 followed by param list. There can be multiple tpa:param sets. 733 Use of the ANY label is not intended to support wildcards for 734 referencing hash labels. No wildcard labels are to be used below the 735 "_tpa." label to access DNS resources. 737 "tpa" tag 738 ad_val = [ANY] domain 739 ad-list = %x74.70.61 *WSP "=" [ ad_val 0*( 1*(WSP) ad_val )] 741 15.1. TPA-Label Resource Record Param Syntax 743 Authorization Param List (Optional). This tag defines a list of 744 assertions for the preceding (if listed) domains which indicate 745 various email-address locations within the message and authorized 746 validation methods. Only recognized param values offer any form of 747 DMARC authorization. The "n" param however excludes the prior tpa 748 list as not being within the federation. 750 "param" tag 751 pa_val = "L" / "S" / "O" / "d" / "e" / "h" / "m" / "n" / "t" 752 pa-list = %x73.63.6f.70.65 *WSP "=" [ pa_val 0*( 1*(WSP) pa_val )] 754 15.2. Header Dependent Authorizations 756 15.2.1. List-ID Header Field 758 The "L" param asserts that authorization is valid only when a List-ID 759 identifier of the List-ID header field [RFC2919] contains a domain 760 that is within a domain listed in the TPA-LLD "tpa" tag. 762 The syntax of the List-Id header field is as follows: 763 list-id-header = "List-ID:" [phrase] "<"identifier">"CRLF 765 15.2.2. Sender Header Field 767 The "S" param asserts that authorization is valid only when the 768 domain in the Sender header field is within the TPA-LLD. 770 15.2.3. OAR Header Field 772 The "O" param asserts that authorization is valid only when the 773 domain in an Original Authentication Results header field indicates 774 it passed based on a domain within the TPA-LLD or the Trusted Domain 775 itself. 777 15.2.4. Combined 'L' or 'S' Params 779 When combined, the params 'L' and 'S' require that either a List-ID 780 identifier of the List-ID header field or the Sender header field 781 must contain a domain within the TPA-LLD for the authorization to be 782 valid. 784 15.3. DKIM signed domain 786 15.3.1. DKIM signed 788 The "d" param asserts that messages carrying the Trusted Domain 789 within the From header field are authorized to be signed by the TPA- 790 LLD. 792 15.4. SMTP Host domains 794 The "e" param asserts that host names given in [RFC5321] EHLO or HELO 795 commands within TPA-LLD is authorized when the hostname resolves the 796 server's IP address. 798 15.5. SMTP Host domains 800 The "h" param asserts that host names given in [RFC5321] EHLO or HELO 801 commands within TPA-LLD is authorized only when this hostname 802 submitted to an SPF [RFC7208] process returns pass. 804 15.6. MailFrom Parameter 806 The "m" param asserts that an email-address domain in the [RFC5321] 807 MAIL command within a TPA-LLD is authorized only when this email- 808 address submitted to an SPF [RFC7208] process returns pass. 810 15.7. Not Federated 812 The "n" param asserts that a previous "tpa" listed domain is 813 specifically not federated and not authorized. The use of this 814 parameter is to suppress subsequent processing that may otherwise be 815 needlessly repeated in the case where the third-party is being 816 detected as conveying user messages but are not authorized for policy 817 related reasons, such as not adequately protecting the Federated 818 Identity. 820 15.8. SMTP Host domains 822 The "t" param asserts that host names given in [RFC5321] EHLO command 823 after [RFC3207] negotiation where the Cert DNS-ID domain is within 824 TPA-LLD is authorized. It will also be interesting to see whether 825 [I-D.ietf-dane-smtp-with-dane] establishes a way to authenticate 826 sending domains. 828 Note to RFC Editor: Remove this comment before publishing. 829 Currently, no general practice employs certificates to confirm the 830 domain of the client initiating a connection. This may be needed 831 for clients within IPv6 IP address space where tunneling, carrier 832 grade NATs, and rapid space assignment without any practical 833 reverse mapping reduces the effectiveness of IP address based 834 reputations. 835 There is an existing TLS option for SMTP and an ongoing effort to 836 standardize automated server confirmation. It might be possible 837 to leverage this effort to establish practices used at the client. 838 See conversations defined in [RFC4954] Section 4. For information 839 related to ongoing server related efforts see: 840 [RFC6125] and [RFC6698] 842 16. TPA-Label Resource Record Query Transactions 844 The discovery of TPA-Label Resource Records need not be subsequent to 845 the discovery of the DMARC record. However, when no DMARC record is 846 discovered which includes the tag value of "tpa", the verifier MAY 847 assume no TPA-Label Resource Records have been published. Otherwise, 848 when there is no Trusted Domain validation, the discovery of TPA- 849 Label Resource Records should be attempted. 851 17. TPA-Label Resource Record Compliance Extension 852 The signing practice compliance assessment of Third Party Signatures 853 is a discretionary operation performed by the verifier. For messages 854 that do not have valid Trusted Domain alignment, a verifier may 855 decide to assess compliance for Third Party messages when there is a 856 DMARC tag of "tpa". Elements then referenced in the TPA-Label param 857 values of "d", "m", "e", "h", "t" are to be checked in their listed 858 succession. One of the following sets of conditions MUST be met for 859 the result to be considered a pass: 861 For Third Party DKIM signatures, the following represents the set of 862 conditions to be checked: 864 o The Third Party Signature MUST validate according to [RFC6376]. 865 o A TXT resource record, referenced by a TPA-Label created by the 866 DKIM signature "d=" tag, MUST exist in DNS. 867 o The discovered TPA-Label Resource Record structure MUST be valid. 868 o The domain that created the TPA-Label MUST be within the TPA-LLD. 869 o Where a param of 'd' is specified, the Trusted Domain MUST have an 870 authorized DKIM signature. 871 o Where a param of 'L' or 'S' is specified, a List-ID identifier in 872 the List-ID header field or a Sender header field MUST contain a 873 domain within the TPA-LLD. This provides Third-Party services a 874 reason to ensure their outbound messages do not spoof these 875 associated header fields. 876 o Where a param of 'O' is specified, an Original Authentication 877 Results header field MUST indicate a pass for the Trusted Domain 878 or for a domain within the TPA-LLD. This parameter requires the 879 message was received from an approved Originating source. 881 For non-DKIM validations, the TXT record discovery process continues 882 until a TPA-Label Resource Record structure is found where: 884 One of the three possible TXT resource records is checked in their 885 listed succession. Each would be referenced by an 'h' or 'e' or 't' 886 related domain given by [RFC5321] EHLO or HELO command, this domain 887 with left-most label omitted, or by an 'm' related email-address 888 domain within the [RFC5321] MAIL command. 890 o The discovered TPA-Label Resource Record Structure is valid. 891 o The domain that created the TPA-Label is within the TPA-LLD. 892 o The domain that created the TPA-Label corresponds with a listed 893 param of 'e', 'h' or 'm' or 't'. 894 o Where a param of 'L' or 'S' is specified, either the domain in 895 List-ID given by [RFC2919] in the List-ID header field is within 896 the TPA-LLD, or a Sender header field contains a domain within the 897 TPA-LLD respectively. 898 o Once these four conditions have been met, for 'h' or 'm' params 899 the domain MUST be confirmed by submitting the domain to an SPF 900 process that then returns pass. The 'e' param MUST be confirmed 901 by a forward DNS reference that resolves the address of the SMTP 902 client. The 't' param MUST be confirmed by the DNS-ID in the 903 client certificate. 905 When the TPA-Label Resource Record can not be retrieved due to some 906 error that is likely transient in nature, such as "SERVFAIL" for 907 example, the result of the TPA-Label Resource Record compliance 908 assessment is "temperror". 910 When the TPA-Label Resource Record retrieval returns a DNS "NOERROR", 911 but not with a single record, the result of the TPA-Label Resource 912 Record compliance assessment is "permerror". 914 When the TPA-Label Resource Record can not be retrieved with a DNS 915 "NXDOMAIN" response, the result of the TPA-Label Resource Record 916 compliance assessment is "nxdomain". 918 18. Alternative Mitigation Strategies 920 18.1. Proposed DKIM-Delegate Signature survives all Message 921 modifications 923 When a domain sends a message to services likely to invalidate DKIM 924 signatures, such as that of a mailing-list, some envision use of a 925 [I-D.kucherawy-dkim-delegate] header field as a type of DMARC 926 disruption prophylactic conveying signed Third-Party Authorizations 927 similar to that of TPA-LLD. 929 The DKIM-Delegate header field is not a DKIM message signature nor 930 can it generally authorize trustworthy sources. This header field 931 represents a signed domain authorization list placed in the header 932 field's 't' tag. To limit its duration, short expiry can be 933 specified in the 'x' tag. Nevertheless, validity of this header 934 field is completely independent of the message body or any other 935 message header field. 937 Since DKIM-Delegate authorization is actually unrelated to any 938 specific message, it offers less protection at the expense of a 939 higher transactional overhead compared to that of the smaller and 940 simpler TPA-LLD transactions. The TPA-LLD resource also better 941 facilitates timely authorization retractions. Before DKIM-Delegate 942 can be as effective, separate and much larger signature resources 943 would be needed for each authorized domain to match the timely de- 944 authorization selectivity the TPA-Label scheme permits. 946 Since either scheme is primarily aimed at circumventing DMARC 947 compliance issues, once adopted, changes to DMARC related validation 948 can quickly bolster DKIM/DMARC legacy shortfalls in a similar fashion 949 to that offered by TPA-LLD. It is even conceivable, that to obtain 950 an automated authorization expiry, a TPA-LLD could signal when a 951 DKIM-Delegate should be included. The TPA-LLD can still reduce the 952 authorization latitude offered by DKIM-Delegate. Unlike TPA-LLD, 953 DKIM-Delegate is unable to stipulate an additional set of required 954 conditions. 956 Since mailing-lists are normally fairly public, bad actors only need 957 to subscribe to obtain a fresh set of DKIM-Delegate header fields as 958 a means to circumvent its expiry feature. Using freshly minted DKIM- 959 Delegate header fields also avoids elements that might be identified 960 as pertaining to a specific campaign at little cost to the 961 malefactor. 963 18.2. Vouch-By-Reference 965 VBR uses a third-party domain referenced in a message header to vouch 966 for the types of messaging expected from a domain verified as part of 967 normal message handling. Since any domain other than the DMARC 968 domain attempting to guard against From header field spoofing is 969 unable to make such assessments, for the purposes of Anti-Phishing, 970 VBR lacks the necessary input and knowledge to offer timely and 971 accurate advice. The nature of Phishing abuse is often too low in 972 frequency for typical Anti-Spam policies to be effective. 974 19. Privacy Considerations 976 Unless all valid Third-Party Domains have been authorized, personally 977 identifiable information will be exchanged within the DMARC feedback. 978 This feedback can unintentionally expose private exchanges made on 979 behalf or the DMARC domain's users. To the greatest extent possible, 980 this feedback information should not be shared with other domains not 981 offering the information. This feedback can even identify mailing- 982 list subscribers that never sent any message to the list, or invoices 983 made on behalf of an accountant's client. 985 As with other authorization schemes that utilize DNS, relationships 986 are publicly revealed. This is the nature of SPF authorization which 987 reveals first party services being used. A TPA-Label on the other 988 hand can resolve a hash obscured Third-Party Service. Unlike SPF, a 989 TPA-Label does not include any user identity related parameters and 990 does not reveal any users specific relationships. In addition, these 991 relationships are accessed with a hash of the entire domain. Use of 992 a few random subdomains can inhibit discovery of these relationships. 994 However, the low latency of DNS means resource records can not be 995 assumed to remain secret. 997 Even so, disclosures of Third-Party Services might be justified by 998 dissuading malefactors who have compromised the Trusted Domain and 999 then are able to subsequently spoof the discovered personal 1000 relationships. Such spoofing might be seen as causing greater harm 1001 than public knowledge of possible Third-Party Services used by the 1002 Trusted Domain's users. 1004 It seems this can not be overstated: The overhead associated with 1005 managing a "_tpa." zone is fairly small and is well offset by 1006 squelching DMARC feedback generation and the remediation of a loss of 1007 legitimate messages. Alternatives to TPA-Labels are likely to be the 1008 dissemination of plaintext lists of domains known to cause alignment 1009 failures, although operating in full compliance with SMTP protocols 1010 and practices. The dissemination of lists lessens the domain's 1011 privacy, and their ability to react to mitigate abuse. 1013 20. IANA Considerations 1015 20.1. Moving RFC6541 to historic 1017 This document is seeking to replace [RFC6541] and to move it to 1018 historic. 1020 20.2. TPA-Label (TPA-LLD) Parameters 1022 To accommodate the extensions to [RFC7001] needs the following 1023 elements to be added: 1025 +------+-----------------+ 1026 | Type | Reference | 1027 +------+-----------------+ 1028 | tpa | (this document) | 1029 +------+-----------------+ 1031 TPA-Label Resource Record validation Method 1033 20.3. Email Authentication Method Registry 1035 To accommodate the method derived from TPA-Label Resource Record 1036 processing, the IANA Registry "Email Authentication Method" defined 1037 by Section 6.2 of [RFC7001] needs the following elements to be added: 1039 +---------+-----------+--------+----------+-------------------------+ 1040 | Method | Defined | ptype | property | value | 1041 +---------+-----------+--------+----------+-------------------------+ 1042 | tpa-lld | (this | domain | 3p-dom | Domain evaluated. The | 1043 | | document) | | | method results from | 1044 | | | | | [RFC7001] should also | 1045 | | | | | be included in a | 1046 | | | | | Authenticated Results | 1047 | | | | | header field. | 1048 | | | | param | value of param | 1049 | | | | | (Section 20.6) tag. | 1050 | | | | | (When 'param' contains | 1051 | | | | | 'e', 'h' or 'm', the | 1052 | | | | | iprev [RFC7001] | 1053 | | | | | (Section 3) method | 1054 | | | | | results should also be | 1055 | | | | | included in the | 1056 | | | | | Authenticated-Results | 1057 | | | | | header field to capture | 1058 | | | | | the SMTP client IP | 1059 | | | | | address. | 1060 | | | | ca-param | The params | 1061 | | | | | (Section 20.6) with a | 1062 | | | | | compliance assessment | 1063 | | | | | as pass | 1064 | | | | tpa | Value of tpa | 1065 | | | | | (Section 15) tag at | 1066 | | | | | time of compliance | 1067 | | | | | assessment | 1068 +---------+-----------+--------+----------+-------------------------+ 1070 TPA-Label Resource Record validation Method 1072 20.4. Email Authentication Result Names Registry 1074 To accommodate the results derived from TPA-Label Resource Record 1075 processing, the IANA Registry "Email Authentication Method" defined 1076 by Section 6.3 of [RFC7001] needs the following elements added: 1078 +----------+----------+---------------------------------------------+ 1079 | code | method | meaning | 1080 +----------+----------+---------------------------------------------+ 1081 | none | tpa-lld | No TPA-Label was published | 1082 | pass | tpa-lld | Section 17 | 1083 | tempfail | tpa-lld | Section 17 | 1084 | permfail | tpa-lld | Section 17 | 1085 | hdrfail | tpa-lld | The TPA-Label Resource Record param values | 1086 | | | of "S" or "L" failed to match. | 1087 | nxdomain | tpa-lld | When obtaining the TPA-Label Resource | 1088 | | | Record, DNS indicated this domain does not | 1089 | | | exist. | 1090 +----------+----------+---------------------------------------------+ 1092 TPA-Label Resource Record complaince assessment Results 1094 20.5. Third Party Authorizations Labels Registry 1096 Names of tags that are valid in TPA-Label Resource Records with the 1097 exception of experimental tags Section 12 MUST be registered in this 1098 created IANA registry. 1100 New entries are assigned only for values that have been documented in 1101 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 1102 [RFC5226]. 1104 Each tag registered must correspond to a definition. 1106 The initial set of values for this registry is: 1108 +-----------------+--------------+----------------------------------+ 1109 | tag | defined | definition | 1110 +-----------------+--------------+----------------------------------+ 1111 | v | Section 12 | Label Version | 1112 | tpa | Section 15 | List of Authorized Domains or | 1113 | | | Identifiers | 1114 | prior tpa param | Section 15.1 | Section 20.6 | 1115 +-----------------+--------------+----------------------------------+ 1117 TPA-Label Resource Record compliance assessment Results 1119 20.6. Third Party Authorizations Param Registry 1121 Values that correspond to Section 15.1 MUST be registered in this 1122 created registry: 1124 New entries are assigned only for values that have been documented in 1125 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 1127 [RFC5226]. 1129 Each value registered must correspond to a definition. 1131 The initial set of values for this registry is: 1133 +------------+----------------+ 1134 | value | defined | 1135 +------------+----------------+ 1136 | L | Section 15.2.1 | 1137 | S | Section 15.2.2 | 1138 | O | Section 15.2.3 | 1139 | d | Section 15.3 | 1140 | h | Section 15.5 | 1141 | e | Section 15.4 | 1142 | m | Section 15.6 | 1143 | n | Section 15.7 | 1144 | t | Section 15.8 | 1145 +------------+----------------+ 1147 TPA-Label Resource Record compliance assessment Results 1149 21. Security Considerations 1151 This draft extends Domain Alignment validation practices that depend 1152 on DKIM [RFC6376] or SPF [RFC7208]. Most related security matters 1153 are discussed in those specifications. Additional considerations are 1154 also included in [RFC6377]. Security considerations for the TPA-LLD 1155 scheme are mostly related to attempts on the part of malefactors to 1156 falsely represent themselves as others, often in an attempt to 1157 defraud either the recipient or the alleged originator. Some 1158 receivers mistakenly bypass validation of the [RFC5322] header fields 1159 because a signature from a Trusted Domain had been confirmed as 1160 perhaps suggested in [RFC5863]. Do not omit the validation of header 1161 fields unless the message is not accepted for other reasons. 1163 Additional security considerations regarding DKIM signing practices 1164 may be found in the DKIM threat analysis [RFC4686]. 1166 21.1. Benefits to Recipients 1168 The verifier, after validating a Federated Domain, will have 1169 significantly greater confidence in the Third-Party, than when no 1170 TPA-Label Resource Record is obtained. This enhanced confidence may, 1171 at the receivers' discretion, cause a message to be delivered to the 1172 recipient with less stringent assessments. 1174 21.2. Risks to Recipients 1176 The decisions a recipient makes in regard to message filtering based 1177 on TPA-Label Resource Records are likely to depend on the system 1178 integrity of the Third Party with respect to the validation methods 1179 determined by authorization param labels. When the 'e', 'h', or 'm' 1180 param domain is not confirmed, or the Third-Party Domain does not 1181 validate the submitter, there is a risk of accepting potentially 1182 spoofed messages. Authentication-Results header fields then play an 1183 important role when there is no out-of-band validations confirming 1184 the submitter. Without proper Authentication-Results handling by the 1185 Third-Party, there is also risk of accepting potentially spoofed 1186 messages. 1188 With the TPA-Label specification, third party validation provides 1189 verifiable value. Implementers should consider the possibility a 1190 malefactor will send a message having a large number of valid DKIM 1191 Signatures. Verifying all the signatures may consume a large amount 1192 of processing resources. As such, it might be worth checking for the 1193 existence of a TPA-Label Resource Record first to minimize network 1194 amplification concerns. Section 16 describes a quick check to see if 1195 TPA-Label Resource Records may exist. Additionally, validating DKIM 1196 signatures and obtaining related resource records might be limited to 1197 known trustworthy domains. 1199 Services that depend only upon path authorizations might permit the 1200 Trusted Domain to be spoofed and yet obtain acceptance. During such 1201 events, the Trusted Domain might need to retract its authorization 1202 from the service. For this reason, path related validation based on 1203 IP addresses should only be used as a carefully monitored interim 1204 solution. 1206 21.3. Benefits to Trusted Domains 1208 TPA-Label Resource Records can replace domain delegations, selector/ 1209 key record mirroring, or key exchanges. A significant number of 1210 details are associated with selector/key records. These details 1211 include user limitations, suitable services, key resource record's 1212 Time-To-Live, revocation and update procedures, and how the DKIM 1213 Signature header field's 'i=' semantics are to be applied. In 1214 addition, services that depend upon DKIM keys are better secured by 1215 not delegating these DKIM keys, where instead the TPA-LLD scheme 1216 allows Trusted Domains an ability to limit the scope of their 1217 authorizations, while also not being mistaken for having validated 1218 the entity submitting the message. 1220 TPA-Label Resource Records convey which domains are authoritative 1221 even when they are not the Trusted Domain. However, Authorized 1222 Domains are unable to utilize the DKIM signature's 'i=' semantics to 1223 directly assert which identifiers on whose behalf a signature was 1224 added. As such, no domain should be authorized unless it is trusted 1225 to ensure the Federated Identity of an email undergoes validation 1226 that offers acceptable protections for the Trusted Domain. For 1227 example, such validation might ensure submitting entities have 1228 demonstrated receipt of "pingback" messages sent to the Federated 1229 Identity (Author's address) contained within the messages being 1230 signed. 1232 By deploying TPA-Label Resource Records, Trusted Domains benefit when 1233 recipients assess the senders' practice compliance by using the TPA- 1234 LLD scheme. These recipients will be less likely to drop the Trusted 1235 Domain's genuine messages, whenever the Trusted Domain attempts to 1236 restrict acceptance. Restricting acceptance of non-compliant 1237 messages is the basic motivation for publishing DMARC records. In 1238 addition, recipients are more likely to validate messages by an 1239 Authorized Domain. 1241 Broader use of strict DMARC alignment assertions provides a greater 1242 likelihood of being able to eliminate a broader range of non- 1243 compliant messages, in addition to improving acceptance from 1244 authorized sources. TPA-Labels also allow Trusted Domains to control 1245 message Sender and List-ID attributes, to exclude problematic 1246 validation methods or include others as they become available. 1248 Trusted Domains having good reputations might extend limited 1249 compliance assessment resources to otherwise unknown domains or SMTP 1250 Clients that are referenced by their TPA-LLD. Conversely, TPA-LLD 1251 resources that assert a domain as not being federated can be used to 1252 suppress any processing that might be otherwise needlessly repeated. 1254 21.4. Risks to Trusted Domains 1256 As indicated in Section 8, it is ultimately an issue of trusting the 1257 Third Party Domain to do the right thing and not generate, or allow 1258 others to generate, messages that falsely appear to be from the 1259 Trusted Domain. The validation methods in place for different email 1260 elements need to be carefully reflected in the "param" tag of the 1261 TPA-LLD. 1263 Authorization of mailing lists with TPA-LLD could cause a loss of 1264 confidentiality in mailing list participation by the Trusted Domain. 1265 This might help malefactors deduce which subscription related email 1266 the Trusted Domain may receive. Because of the hashing function in 1267 generating the TPA-Label, anyone wishing to discover which domains 1268 are being authorized, has to probe each TPA-Label based on the exact 1269 domain. In addition, service organizations or community groups are 1270 able to share comprehensive lists. Such possible sharing means even 1271 though a domain has been authorized, that in itself does not mean the 1272 Trusted Domain is exchanging messages with the Authorized Domain. 1274 21.5. Benefits to Third Party Signers 1276 Third Party Signers benefit by allowing those using their service, 1277 the autonomy to authorize their service without needing to exchange 1278 DKIM key related details. This is particularly useful for mailing 1279 lists. 1281 21.6. Risks caused by Third Party Signers 1283 As mentioned before, Authorized Third Party Signers need to validate 1284 messages from Trusted Domains. This validation provides a safety 1285 mechanism for the Trusted Domain and their recipients. The Third 1286 Party may not be aware of the validation value or the message 1287 elements involved, and as a result make changes without understanding 1288 the impact this may have on Trusted Domains and their recipients. 1289 For example, the Third Party might stop DKIM signing or stop applying 1290 Authentication-Results header fields. The unexpected exposure that 1291 this might enable could allow abuse and prove detrimental for both 1292 the Trusted Domain and their recipients. 1294 21.7. SHA-1 Collisions 1296 The use of the SHA-1 hash algorithm does not represent a security 1297 concern. The hash simply ensures a deterministic domain-name size is 1298 achieved. Unexpected collisions can be detected and handled by using 1299 the extended TPA-Label Resource Record "tpa=" option. The use of 1300 TPA-Label Resource Records without the TPA-Label "tpa=" options does 1301 present an opportunity for an adversary to attempt to find a hash 1302 collision. Message spoofing outside the realm of DKIM protection is 1303 likely easier to achieve than finding hash collisions. There is 1304 minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains has 1305 less than a 0.1 percent risk of any two domain labels colliding. 1307 21.8. DNS Limits 1309 Use of the TPA-Label Resource Records, rather than simply listing the 1310 Authorized Domain, ensures the DNS record size is independent of the 1311 Third Party Domain. The typical domain name size has been steadily 1312 increasing. This increase has been caused by domain names that 1313 encode international character sets. Perhaps, soon there will be a 1314 further increase spurred by an expanse of TLDs having larger 1315 international labels. 1317 The maximum domain name size allowed, per [RFC1034] Section 3, is 255 1318 bytes (or octets). Each label has a byte for its length. Every 1319 domain name adds an additional byte by having a right-most label that 1320 represents the root "." signified as a zero length label. A labeling 1321 scheme that combines together a listed domain with the publishing 1322 domain separated by some label for this convention, reduces the 1323 maximal domain name in half, where the convention label reduces this 1324 further. 1326 If "_smtp._tpa." were used as the convention label with a simple 1327 listing method, the maximum domain name size this supports would be 1328 128 bytes. The suffix for TPA-Labels is "_smtp._tpa." which consumes 1329 11 bytes. The TPA-Label itself consumes 34 bytes. A domain that 1330 publishes the TPA-Labels in its domain would then have 122 bytes 1331 available for their Trusted Domain. This permits the authorization 1332 of any domain having a valid length with a deterministic amount of 1333 space available for resource records. 1335 Normally, DNS messages should not exceed 512 bytes as per Section 1336 2.3.4 of [RFC1035]. Using TPA-Label Resource Records in the DNS, as 1337 described by this document, consumes a consistent 50 bytes, in 1338 addition to the domain name publishing the TPA-Labels. With this 1339 being constant, a limit can be determined as a constraint to resource 1340 record size, to ensure a response does not exceed the maximum DNS 1341 message size. DNS servers that add additional resource records, for 1342 nameservers as an example, will further reduce available resource 1343 record capacity. Domains publishing TPA-Labels exceeding the DNS 1344 message limit will need to rely on recipients using TCP for DNS 1345 retrieval, or EDNS0 [RFC6891] for extended DNS lengths. 1347 22. Acknowledgements 1349 Jeff MacDonald, Michael Deutschmann, Frank Ellermann, Murray 1350 Kucherawy, Wietse Venema, Alessandro Vesely, and John Leslie. 1352 23. References 1354 23.1. Normative References 1356 [FIPS.180-2.2002] 1357 National Institute of Standards and Technology, "Secure 1358 Hash Standard", FIPS PUB 180-2, August 2002, . 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, March 1997. 1364 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1365 and Namespace for the Identification of Mailing Lists", 1366 RFC 2919, March 2001. 1368 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1369 Transport Layer Security", RFC 3207, February 2002. 1371 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1372 Encodings", RFC 4648, October 2006. 1374 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1375 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1377 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1378 October 2008. 1380 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1381 October 2008. 1383 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1384 July 2009. 1386 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1387 Verification of Domain-Based Application Service Identity 1388 within Internet Public Key Infrastructure Using X.509 1389 (PKIX) Certificates in the Context of Transport Layer 1390 Security (TLS)", RFC 6125, March 2011. 1392 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1393 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1394 September 2011. 1396 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1397 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 1399 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 1400 Message Authentication Status", RFC 7001, September 2013. 1402 23.2. Informative References 1404 [I-D.ietf-dane-smtp-with-dane] 1405 Dukhovni, V. and W. Hardaker, "SMTP security via 1406 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 1407 (work in progress), May 2014. 1409 [I-D.kucherawy-dkim-delegate] 1410 Kucherawy, M. and D. Crocker, "Delegating DKIM Signing 1411 Authority", draft-kucherawy-dkim-delegate-01 (work in 1412 progress), June 2014. 1414 [I-D.kucherawy-dmarc-base] 1415 Kucherawy, M. and E. Zwicky, "Domain-based Message 1416 Authentication, Reporting and Conformance (DMARC)", 1417 draft-kucherawy-dmarc-base-04 (work in progress), 1418 April 2014. 1420 [I-D.kucherawy-original-authres] 1421 Chew, M. and M. Kucherawy, "Original-Authentication- 1422 Results Header Field", draft-kucherawy-original-authres-00 1423 (work in progress), February 2012. 1425 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1426 STD 13, RFC 1034, November 1987. 1428 [RFC1035] Mockapetris, P., "Domain names - implementation and 1429 specification", STD 13, RFC 1035, November 1987. 1431 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1432 selection, and registration of an Autonomous System (AS)", 1433 BCP 6, RFC 1930, March 1996. 1435 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1436 Identified Mail (DKIM)", RFC 4686, September 2006. 1438 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1439 for Authentication", RFC 4954, July 2007. 1441 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1442 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1443 May 2008. 1445 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 1446 Reference", RFC 5518, April 2009. 1448 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1449 "DomainKeys Identified Mail (DKIM) Development, 1450 Deployment, and Operations", RFC 5863, May 2010. 1452 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1453 Mailing Lists", BCP 167, RFC 6377, September 2011. 1455 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 1456 Authorized Third-Party Signatures", RFC 6541, 1457 February 2012. 1459 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1460 DNS", RFC 6672, June 2012. 1462 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1463 of Named Entities (DANE) Transport Layer Security (TLS) 1464 Protocol: TLSA", RFC 6698, August 2012. 1466 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1467 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1468 April 2014. 1470 Appendix A. DNS Example of TPA-Label Resource Record placement 1472 #### 1473 # Practices for Example.com email domain using example.com, isp.com, 1474 # and example.com.isp.com as signing domains. 1475 #### 1477 #### 5322.From authorization for 3P domains #### 1479 ## "isp.com" TPA-Label Resource Record ## 1480 _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com. IN TXT 1481 "v=tpa1; tpa=isp.com; param=d;" 1483 #### 5322.Sender/List-ID authorization for 3P domains #### 1485 ## "example.com.isp.com" TPA-Label Resource Record ## 1486 _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._smtp._tpa.example.com. IN TXT 1487 "v=tpa1 tpa=*.isp.com; param=d L S;" 1489 Appendix B. C code for label generation 1491 The following utility can be compiled as TPA-Label.c using the 1492 following: 1494 gcc -lcrypto TPA-Label.c -o TPA-Label 1496 1497 /* 1498 * TPA-Label generation utility 1499 * Copyright (c) 2010 IETF Trust and the persons identified as the 1500 * document authors. All rights reserved. 1501 * 1502 * This document is subject to BCP 78 and the IETF Trust's Legal 1503 * Provisions Relating to IETF Documents 1504 * (http://trustee.ietf.org/license-info) in effect on the date of 1505 * publication of this document. Please review these documents 1506 * carefully, as they describe your rights and restrictions with respect 1507 * to this document. Code Components extracted from this document must 1508 * include Simplified BSD License text as described in Section 4.e of 1509 * the Trust Legal Provisions and are provided without warranty as 1510 * described in the Simplified BSD License. 1511 * 1512 * This document and the information contained herein are provided on an 1513 * "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1514 * OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1515 * THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1516 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1517 * THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1518 * WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1519 */ 1520 #include 1521 #include 1522 #include 1523 #include 1524 #include 1525 #include 1526 #include 1527 #include 1528 #include 1529 #include 1530 #include 1532 #define TPA_LABEL_VERSION 102 1533 #define MAX_DOMAIN_NAME 256 1534 #define MAX_FILE_NAME 1024 1536 static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; 1537 static char sign_on[] = 1538 {"%s v%d.%02d Copyright (C) (2014) The IETF Trust\n"}; 1539 char err_cmd[] =\ 1540 "ERR: Command error with [%s]\n"; 1541 char use_txt[]=\ 1542 "Usage: TPA-Label [-i domain_input_file] [-o label_output_file][-v]\n"; 1543 char help_txt[]=\ 1544 "The options are as follows:\n"\ 1545 "-i domain name input. Defaults to stdin. Removes trailing '.'\n"\ 1546 "-o TPA-Label output. Defaults to stdout.\n"\ 1547 "-v Specifies Verbose Mode.\n\n"; 1549 static void usage(void); 1550 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1552 static void 1553 usage(void) 1554 { 1555 (void) fprintf(stderr, "\n%s%s", use_txt, help_txt); 1556 exit(1); 1557 } 1558 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1560 int 1561 main (int argc, char * argv[]) 1562 { 1563 int ret_val, in_mode, out_mode, verbose, done, i, j, k; 1564 char ch; 1565 unsigned int len; 1566 unsigned long b_5; 1567 char in_fn[MAX_FILE_NAME], out_fn[MAX_FILE_NAME]; 1568 unsigned char in_buf[MAX_DOMAIN_NAME + 2]; 1569 unsigned char sha_res[20], tpa_label[33]; 1570 FILE *in_file, *out_file; 1572 ret_val = in_mode = out_mode = verbose = done = 0; 1573 len = 0; 1575 while ((ch = getopt(argc, argv, "i:o:v")) != -1) 1576 { 1577 switch (ch) 1578 { 1579 case 'i': 1580 in_mode = 1; /* input from file */ 1581 (void) strncpy(in_fn, optarg, sizeof(in_fn)); 1582 in_fn[sizeof(in_fn) - 1] = '\0'; 1583 break; 1584 case 'o': 1586 out_mode = 1; /* out to file */ 1587 (void) strncpy(out_fn, optarg, sizeof(out_fn)); 1588 out_fn[sizeof(out_fn) - 1] = '\0'; 1589 break; 1590 case 'v': 1591 verbose = 1; 1592 break; 1593 case '?': 1594 default: 1595 (void) usage(); 1596 break; 1597 } 1598 }; 1600 if (in_mode) 1601 { 1602 if ((in_file = fopen(in_fn, "r")) == NULL) 1603 { 1604 (void) fprintf(stderr, 1605 "ERR: Error opening [%s] input file.\n", 1606 in_fn); 1607 exit(2); 1608 } 1609 } 1610 else 1611 { 1612 in_file = stdin; 1613 } 1615 if (out_mode) 1616 { 1617 if ((out_file = fopen(out_fn, "w")) == NULL) 1618 { 1619 (void) fprintf(stderr, 1620 "ERR: Error opening [%s] output file.\n", 1621 out_fn); 1622 exit(3); 1623 } 1624 } 1625 else 1626 { 1627 out_file = stdout; 1628 } 1630 if (out_mode && verbose) 1631 { 1632 (void) printf(sign_on, "TPA-Label utility", 1633 TPA_LABEL_VERSION / 100, 1634 TPA_LABEL_VERSION % 100); 1635 } 1637 for (i = 0; i < MAX_DOMAIN_NAME && !done; i++) 1638 { 1639 if ((ch = fgetc(in_file)) == EOF) 1640 { 1641 ch = 0; 1642 } 1643 else if (ch == '\n' || ch == '\r') 1644 { 1645 ch = 0; 1646 } 1648 in_buf[i] = tolower(ch); 1650 if (ch == 0) 1651 { 1652 len = i; /* string length */ 1653 done = 1; 1654 } 1655 } 1657 if (!done) 1658 { 1659 (void) fprintf(stderr, "ERR: Domain name too long.\n"); 1660 exit (4); 1661 } 1663 if (len && in_buf[len - 1] == '.') /* remove any trailing "." */ 1664 { 1665 len--; 1666 in_buf[len] = 0; /* replace trailing "." with 0 */ 1667 } 1669 in_buf[len] = 0; /* terminate string */ 1671 if (len < 2) 1672 { 1673 (void) 1674 fprintf(stderr, 1675 "ERR: Domain name [%s] too short with %d length.\n", 1676 in_buf, 1677 len); 1678 exit (5); 1679 } 1681 SHA1(in_buf, len, sha_res); 1682 if (verbose) 1683 { 1684 printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len); 1686 for (i = 0; i < 20; i++) 1687 { 1688 printf("%02x", sha_res[i]); 1689 } 1690 printf("\nTPA-Label 5 bit intervals left to right.\n"); 1691 } 1693 /* process sha1 results 4 times by 40 bits (160 bits) */ 1694 for (i = 0, j = 0; i < 4 ; i++) 1695 { 1696 b_5 = (unsigned long long) sha_res[(i * 5)] << 32; 1697 b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24; 1698 b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16; 1699 b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8; 1700 b_5 |= (unsigned long long) sha_res[(i * 5) + 4]; 1702 if (verbose) 1703 { 1704 printf(" {%010llX}->", b_5); 1705 } 1707 for (k = 35; k >= 0; k-= 5, j++) /* convert 40 bits (5x8) */ 1708 { 1709 tpa_label[j] = base32[(b_5 >> k) & 0x1F]; 1711 if (verbose) 1712 { 1713 printf(" %02X:%c", 1714 (unsigned int)(b_5 >> k) & 0x1F, 1715 tpa_label[j]); 1716 } 1717 } 1718 if (verbose) 1719 { 1720 printf ("\n"); 1721 } 1722 } 1723 if (verbose) 1724 { 1725 printf("\n"); 1726 } 1727 tpa_label[j] = 0; /* terminate label string */ 1728 fprintf(out_file, "_%s", tpa_label); 1729 printf("\n"); 1730 /* close */ 1731 if (out_mode) 1732 { 1733 if (fclose (out_file) != 0) 1734 { 1735 (void) fprintf(stderr, 1736 "ERR: Unable to close %s output file.\n", 1737 out_fn); 1738 ret_val = 6; 1739 } 1740 } 1741 if (in_mode) 1742 { 1743 if (fclose (in_file) != 0) 1744 { 1745 (void) fprintf(stderr, 1746 "ERR: Unable to close %s input file.\n", 1747 in_fn); 1748 ret_val = 7; 1749 } 1750 } 1751 return (ret_val); 1752 } 1753 1755 Appendix C. History of Prior Efforts 1757 To withstand asserting strict alignment practices, a scheme was 1758 devised that transferred the burden of a resulting disruption from 1759 receivers back to the Trusted Domains making the stringent requests. 1760 As such, a method to authorize other validated domains to establish 1761 informally Federated Third-Party Services, such as mailing-lists was 1762 developed. This initial scheme was then modified and proposed by 1763 ATPS [RFC6541]. Unlike the initial scheme, ATPS required Third-Party 1764 Services to use specific non-standard DKIM signatures to signal use 1765 of the ATPS authorization strategy. ATPS also required the DKIM 1766 signatures used by Third-Party Services to somehow determine the 1767 different label encoding employed by the many Trusted Domains without 1768 any defined discovery or exchange method. 1770 Both of these changes made deployment impractical by impacting 1771 systems not benefiting from additional alignment requirements. 1772 Third-parties have often been offering free services for decades. 1773 Even renaming From headers would impair normal handling. Those 1774 offering these services should not be expected to carry the burden of 1775 enabling a new Trusted Domain compliance scheme. Trusted Domains 1776 should offer the information needed to avoid disrupting these 1777 services instead, which is the purpose of TPA-Labels. 1779 Rather, the Trusted Domain seeking cooperative handling and receiving 1780 receiver feedback necessary to mitigate disruption should handle this 1781 burden instead. It is the Trusted Domain that directly benefits 1782 after all. There should not be unnecessary and problematic encoding 1783 schemes or assertions of delivery chains being expected of any Third- 1784 Party Service. Such matters are simply not their concern nor in 1785 their benefit. 1787 It seems the added complexities found in ATPS were to defend against 1788 a single DNS transaction. However, before this transaction occurs, 1789 the Third-Party must permit the validation of their own domain. Even 1790 then, a Third-Party checking transaction only occur after the domain 1791 is not within the Trusted Domain's alignment assertions. An 1792 assertion that can always be removed at any point. It is clearly in 1793 the interest of the Trusted Domain where the checking transaction 1794 represents a very minor contribution in support of desired receiver 1795 cooperation. 1797 Tailoring their TPA-Label list to suit their own users should 1798 discourage non-cooperative references to their domain. As more 1799 domains reference a common "_tpa." zone, the clout of that zone 1800 increases at a very moderate cost. This additional clout better 1801 ensures timely responses to abuse notifications. In this manner, 1802 DMARC/TPA-Labels would be helping to improve anti-abuse cooperation. 1803 In that light, TPA-Labels should be considered a sound investment and 1804 not an unwanted burden. 1806 ATPS required new tags be included in Third-Party DKIM signatures. 1807 These were "atps" and "atpsh" to construct a chain of "d=" and 1808 "atps=". This added complexity without any immediate benefit. 1809 Determining optional label encoding without any defined discovery 1810 method overlooks that authorization is only possible after the Third- 1811 Party Domain has been validated. A complete lack of ATPS deployment 1812 should have been expected since necessary changes did not align with 1813 benefits. 1815 In contrast, TPA-Labels do not require ANY change be made by 1816 authorized third-parties. Disrupting legitimate communications 1817 imposes inordinate support costs as a result of erroneously asserting 1818 strict alignment practices. The resulting disruption will eventually 1819 cause the domain's assertions to be ignored. If this disruption 1820 becomes endemic, assertions of other domains will become ignored as 1821 well. Domains wishing to benefit from their handling advice being 1822 employed while sending legitimate messages that may not retain their 1823 asserted alignment practices, should be offering the needed TPA-Label 1824 exception information. This information is essential and is only 1825 known by the Trusted Domain through their DMARC feedback. 1827 At this time, it is not practical for large ISPs to make strict DMARC 1828 assertions. Strict alignment assertions exclude normal Third-Party 1829 Services that modify the requisite alignment. TPA-Label lists 1830 specifically tailored to handle their users' desired Third-Party 1831 Services will permit their users to have normal email use. While 1832 entailing some administrative effort, TPA-Labels will generally be of 1833 benefit to their users by widely discouraging any spoofing of their 1834 messages. This affords greater protection for the users and the 1835 user's recipients. 1837 SPF purported to provide an anti-spoofing feature for an unseen 1838 parameter. Nevertheless, its strict IP address authorization causes 1839 problems and is largely disregarded for anything other than limiting 1840 the sending of DSNs or the scoring of messages. Many institutions 1841 will benefit by ensuring their strict DMARC assertions are not 1842 disruptive. Exercising this care will help retain recipient's trust 1843 in their assertions and the veracity of their messages. TPA-Labels 1844 would allow these institutions a means to use informal Third-Party 1845 Services with minimal administrative effort. Rather than using 1846 subdomains that lack DMARC restrictions, suitable Third-Party 1847 Services can be authorized by TPA-Labels. This approach offers a 1848 proactive method for recipients to better filter possible phishing 1849 attempts by not exposing them to unrestricted subdomain abuse. 1851 TPA-Label publishing is similar to VBR ([RFC5518]). However, it 1852 leverages Third-Party validation confirmed by labels held in the 1853 Trusted Domain. DNS also permits the information to be transparently 1854 made available from other domains whenever desired. TPA-Labels 1855 provide domains a means to protect their recipients while still 1856 permitting the use of legitimate SMTP exchanges. By implementing 1857 DMARC/TPA-Labels, these domains should be better able to stand on 1858 their own merit. 1860 Authors' Addresses 1862 Douglas Otis 1863 Trend Micro 1864 10101 N. De Anza Blvd 1865 Cupertino, CA 95014 1866 USA 1868 Phone: +1.408.257-1500 1869 Email: doug_otis@trendmicro.com 1870 Daniel Black 1871 Canberra ACT 1872 Australia 1874 Email: daniel.subs@internode.on.net