idnits 2.17.1 draft-otis-tpa-label-01.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 1415 has weird spacing: '... int ret_v...' == Line 1495 has weird spacing: '... else if (c...' -- The document date (May 28, 2014) is 3613 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 577, but not defined == Missing Reference: 'ANY' is mentioned on line 703, but not defined -- Looks like a reference, but probably isn't: '20' on line 1421 -- Looks like a reference, but probably isn't: '33' on line 1421 ** 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 (-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 (~~), 7 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: November 29, 2014 May 28, 2014 7 Third-Party Authorization Label 8 draft-otis-tpa-label-01 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 November 29, 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 . . . . . . . . 6 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 . . . . . . . . . . . . . . 11 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 . 12 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 . . . 13 81 8.4.4. Use of Path Authorization . . . . . . . . . . . . . . 13 82 9. DNS Representation . . . . . . . . . . . . . . . . . . . . . . 13 83 10. TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . . 14 84 11. TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 14 85 12. TPA-Label TXT Resource Record Structure . . . . . . . . . . . 15 86 13. TPA-Label Resource Record Definition . . . . . . . . . . . . . 17 87 14. TPA-Label Resource Record Version . . . . . . . . . . . . . . 17 88 15. TPA-Label Resource Record Scope Syntax . . . . . . . . . . . . 17 89 15.1. Authorized Validated Domains . . . . . . . . . . . . . . . 17 90 15.2. Header Dependent Authorizations . . . . . . . . . . . . . 18 91 15.2.1. List-ID Header Field . . . . . . . . . . . . . . . . . 18 92 15.2.2. Sender Header Field . . . . . . . . . . . . . . . . . 18 93 15.2.3. Combined 'L' or 'S' Scopes . . . . . . . . . . . . . . 18 94 15.3. DKIM signed domain . . . . . . . . . . . . . . . . . . . . 18 95 15.3.1. DKIM signed . . . . . . . . . . . . . . . . . . . . . 19 97 15.4. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 98 15.5. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 99 15.6. MailFrom Parameter . . . . . . . . . . . . . . . . . . . . 19 100 15.7. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 101 16. TPA-Label Resource Record Query Transactions . . . . . . . . . 20 102 17. TPA-Label Resource Record Compliance Extension . . . . . . . . 20 103 18. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 21 104 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 19.1. Moving RFC6541 to historic . . . . . . . . . . . . . . . . 22 106 19.2. TPA-Label (TPA-LLD) Parameters . . . . . . . . . . . . . . 22 107 19.3. Email Authentication Method Registry . . . . . . . . . . . 23 108 19.4. Email Authentication Result Names Registry . . . . . . . . 24 109 19.5. Third Party Authorizations Labels Registry . . . . . . . . 24 110 19.6. Third Party Authorizations Scope Registry . . . . . . . . 25 111 20. Security Considerations . . . . . . . . . . . . . . . . . . . 25 112 20.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 25 113 20.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 26 114 20.3. Benefits to Trusted Domains . . . . . . . . . . . . . . . 26 115 20.4. Risks to Trusted Domains . . . . . . . . . . . . . . . . . 27 116 20.5. Benefits to Third Party Signers . . . . . . . . . . . . . 28 117 20.6. Risks caused by Third Party Signers . . . . . . . . . . . 28 118 20.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 28 119 20.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 28 120 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 121 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 122 22.1. Normative References . . . . . . . . . . . . . . . . . . . 29 123 22.2. Informative References . . . . . . . . . . . . . . . . . . 30 124 Appendix A. DNS Example of TPA-Label Resource Record placement . 32 125 Appendix B. C code for label generation . . . . . . . . . . . . . 33 126 Appendix C. History of Prior Efforts . . . . . . . . . . . . . . 38 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 129 1. Introduction 131 A TPA-Label Resource Record supports an authorization of separately 132 validated domains. This added authorization step avoids a need to 133 share private credentials. Also, it ensures each domain remains 134 apparent and open to validation when establishing an informal 135 federation of domains protecting Federated Domain Identities. To 136 improve security, authorization records may also limit how they are 137 to be applied. 139 With TPA-Label Resource Records, mailing lists, among similar Third- 140 Party Domain services, can indirectly assert protection of identities 141 when the source domain is within an informally Federated Domain. 142 Since mailing-lists receive differently formatted messages, a common 143 practice is to convert multi-party conversations into consistent and 144 compact formats facilitating the organization of the many multi-party 145 conversations. Such processing often breaks any meaningful message 146 signature. With the proposed scheme, trusting the federated message 147 source can supersede broken alignment validation. 149 Trusted Domains can seek to ensure the domains they federate protect 150 the Federated Identity. In situations where the Trusted Domain 151 cannot be confirmed, TPA-Labels are able to signal which domains are 152 within the Trusted Domain's informally established federation. When 153 a user wishes to utilize an informal Third-Party Domain service, it 154 is both logical and desirable to retain the original Federated 155 Identity to better convey who substantially created message content. 156 Not retaining this identity would otherwise prohibit subsequent 157 review of prior exchanges. However, when recipients wish to 158 determine whether to trust the Federated Identity, Domain Alignment 159 with the validated source may not exist. TPA-Labels can indicate 160 whether the source domain has been informally federated by the 161 Trusted Domain. 163 2. Terminology 165 Please see [RFC5598] for general email terminology. 167 The following additional terms are used: 169 Transparent Domain Authorization: Third-Party Domains validating as 170 the Trusted Domain represent a type of transparent authorization. 171 This method normally depends on securely sharing private details 172 between domain owners and providers. However, private sharing 173 between different administrative domains is expensive and carries 174 some risk a security breach may result in the wrong administration 175 being held accountable or more resources being placed in peril. 177 Trusted Domain: Often a visible domain that acts as a basis for 178 acceptance and/or subsequent actions. For DMARC, this is the 179 fully qualified domain name found in the From header field. 181 Author Domain: See Section 3 of DMARC ([I-D.kucherawy-dmarc-base] 182 specifying the domain of the From header field which represents 183 the Trusted Domain. 185 Federated Domain: A domain (among possibly others) working in 186 concert with the Trusted Domain authorized as protecting Federated 187 Identifiers. 189 Federated Identity: Identity protected by a Federated Domain. In 190 the case of DMARC, this identity is contained in the From header 191 field. 193 Domain Alignment: Strict alignment requires matching the Trusted 194 Domain. Relaxed alignment allows source domains to be a sub- 195 domain of the Trusted Domain. 197 Third-Party Authorization: A different domain authorized by the 198 Trusted Domain. 200 Informal Third-Party Service: A Service not by the Trusted Domain 201 that does not require administrative cooperation for users to 202 independently establish their own access credentials. 204 Third-Party Service: A Service not by the Trusted Domain. 206 Third-Party Domain: A domain that is not the Trusted Domain. 208 TPA-Label Authorization: The referencing domain which meets the 209 validation and header field content requirements of the resolved 210 TPA-Label Resource Record is thereby authorized by the Trusted 211 Domain. 213 TPA-Label Listed Domain, TPA-LLD: TPA-Label Listed Domain, TPA-LLD, 214 is a TXT Resource Record referenced with the hash value of the 215 domain being authorized. This Resource Record is published within 216 a Trusted Domain. When a "tpa" tag exists, the referencing domain 217 (the domain used to generate the label) must be within the listed 218 domains. When the "tpa" tag does not exist, the referenced domain 219 is presumed. The "scope" tag may stipulate a required existence 220 of additional header fields, or indicate alternate domain 221 validation methods to be applied against specific elements. 223 3. Domain Validation Issues 225 Changing the validated domain, the one referenced by SPF [RFC7208], 226 or the one adding a DKIM [RFC6376] signature, is not a problem since 227 it is rare for acceptance to be based on From header field Domain 228 Alignment. However, when acceptance is based on the From header 229 field alignment, as in the case of DMARC [I-D.kucherawy-dmarc-base] 230 using either SPF or DKIM, this can disrupt many Third-Party Services. 231 The disruption becomes egregious when messages from the domain's own 232 users are rejected based on the level of this domain's asserted 233 alignment practices. At the strictest alignment level, an erroneous 234 assertion not only disrupts messages from their users, it can also 235 affect subscriptions for other users of the Third-Party Service. 237 DKIM, unlike SPF, permits better retention of From/signature 238 alignment where only the From header field could be signed. 239 Nevertheless, the integrity of the original DKIM signature is likely 240 affected by message flattening, inclusion of Subject tags, or 241 appended list footer information. Just signing the From header field 242 is not a practical solution, because it would expose this message 243 fragment to replay abuse, even when given short signature expiry. 245 TPA-Label authorization may individually authorize domain validation 246 methods. This may either increase or decrease the number of 247 validation methods normally used. For example, a virtual server may 248 share an IP address with thousands of different domains. Its 249 authorization may need to exclude IP addresses as a basis for 250 validation. In the TPA-Label scheme, unless a validation method is 251 asserted, no changes to the domain validation process should be 252 assumed. 254 4. Incomplete Assertions Not Congruent with SMTP 256 A few large domains have had a high percentage of user accounts 257 compromised. These events have given malefactors access to prior 258 private exchanges and contact lists. Even after accounts had been 259 reclaimed, malefactors continue sending convincing spoofed messages 260 from other sources. To mitigate harm, some domains have asserted 261 Domain Alignment practices similar to those used by domains that only 262 emit transactional messaging where a recommendation is normally 263 heeded. In addition, some domains also recommended "reject" rather 264 than "quarantine" as a misalignment response. In conjunction with 265 misleading alignment assertions, rejection becomes a highly 266 disruptive choice. 268 It is unfair to place a burden on receivers and expect them to be 269 cooperative. Trusted Domains have access to information that 270 receivers do not. This information is necessary to prevent the 271 disruption of otherwise legitimate messages from their users, and it 272 can be passed on to receivers using TPA-Labels. Prior to making 273 alignment assertions that are likely to disrupt services carrying 274 legitimate messages, Trusted Domains should publish TPA-Labels that 275 list their compilation of Third-Party Domains conveying their users' 276 messages. When Trusted Domains proactively guard against disruption 277 of legitimate messages, receivers are then more likely to cooperate 278 with their recommendations. 280 5. Why DMARC 282 Deterrents based upon reputation and/or path based scoring strategies 283 that utilize a variety of originating header fields has proved 284 ineffective. The header fields often remain invisible to recipients, 285 and contain domains exploited for periods measured in hours, to avoid 286 any Whack-A-Mole like response. Even long term reputations have 287 issues due to an intermix of messages from compromised accounts. 288 Content filtering is unable to keep up with the polymorphic abuse. 289 Few recipients will inspect the stack of message header fields, or be 290 able to draw useful conclusions from a profusion of unfriendly 291 information. As a result, many recipients deal with abuse by sorting 292 messages into groups based on assumed sources found in a few 293 originating header fields. 295 DMARC represents an open registry that offers domain specific 296 guidance for DKIM/SPF alignment sending practices to determine 297 whether messages should be delivered, quarantined, or refused. 298 However, appropriate actions become unclear whenever Third-Party 299 Services are involved. Although DMARC warns of a potential for 300 disruption, the specific handling requested by DMARC is very limited. 301 DMARC expects receivers to devise their own special handling to 302 mitigate disruptions that DMARC assertions might cause for legitimate 303 messaging. This is unfortunate, since the necessary feedback is 304 given to the Trusted Domain and not to the cooperating receivers. 305 TPA-Labels can ensure recipients are provided this necessary 306 information. 308 Administrative domains, that assert all of their outbound message 309 sources can be validated as having aligned domains, offer significant 310 forensic value. However, messages where domains are not in alignment 311 remain a potential issue. Only domains offering messages of a 312 transactional nature do not benefit from the use of TPA-Labels. 314 This document describes how any Trusted Domain publishing DMARC 315 records can autonomously authorize other validated domains. TPA- 316 Labels offer secondary compliance options whenever authorized 317 exceptions are needed to permit the use of Third-Party Domains. The 318 intended purpose of TPA-Label Resource Records is to improve 319 acceptance rates of genuine messages, to minimize DNS use, to 320 minimize success rates for phishing, to improve sorting protections, 321 and to minimize a recipient's administrative costs. 323 TPA-Label Resource Records authorize Third-Party Domains and services 324 to extend compliance options for asserted practices defined by 325 [I-D.kucherawy-dmarc-base]. Domains, that both reference and are 326 listed, and also comply with a TPA-Label resource record, should be 327 considered equivalent to the authorizing Trusted Domain when 328 assessing compliance with DMARC asserted practices. 330 6. TPA-Label Listed Domain, TPA-LLD, 332 TPA-Label Listed Domain, TPA-LLD, is a TXT resource record referenced 333 with a TPA-Label published within a Trusted Domain. When a "tpa" tag 334 exists within the TXT resource record located at the TPA-Label, the 335 referencing domain (the domain used to generate the label) must be 336 within the listed domain. When the "tpa" tag does not exist, the 337 referenced domain is presumed listed. The "scope" tag may stipulate 338 existence of additional header fields, or indicate alternate 339 validation methods applied against specific email elements. 341 Third-Party Domain validation might use a DKIM signature or confirm 342 the Authorized Domain using specific methods with various path 343 related email elements. The default assertion for scope is 'd' and 344 'm', indicating DKIM or the Mail From parameter processed by SPF 345 confirms the Authorized Domain when no other method is specified. 346 The 'S' and 'L' scope does not confirm the domain, but requires at 347 least one Sender or List-ID header field to hold the identity of the 348 Authorized Domain respectively. The 'e', 'h', and 't' indicate 349 specific alternative methods using message elements to confirm the 350 Authorized Domain. When any method scope is asserted (denoted by a 351 lower case letter), methods not listed should not be considered to 352 provide valid results. Being compliant with TPA-LLD allows the 353 referencing domain to informally act on behalf of the Trusted Domain. 354 Per [RFC5321], domain name comparisons, as well as TPA-Labels, are 355 case insensitive. 357 7. TPA-Label Resource Record Authorization Considerations 359 When a Trusted Domain is not within a DKIM or SPF validated domain, 360 the TPA-LLD scheme can extend Domain Alignment compliance. The TPA- 361 LLD scheme with an 'S', or 'L' scope requires the respective Sender 362 header field or a List-ID identifier of the List-ID header field to 363 exist for at least one of the scopes, and to contain a domain within 364 the TPA-LLD for authorization to be valid. The 'd' scope permits 365 validations based upon the DKIM signing domain. The 'm' scope 366 permits validations based upon the return path (Mail From) domain. 367 The 'e', 'h', and 't' scopes permit acceptance based upon validation 368 of the client hostname (EHLO/HELO). 370 The 'S' and 'L' scopes support message sorting. Any matching header 371 field with a domain within the TPA-LLD allows recipients to 372 differentiate sources, which satisfies requirements for any other 'S' 373 or 'L' scope. The 'S' and 'L' scopes provide Trusted Domains a means 374 to limit domain authorizations. 376 The TPA-LLD scheme plays the role of only qualifying acceptable 377 domains with the goal of improving delivery acceptance, such as 378 messages from specific mailing-lists. The TPA-LLD authorization 379 scheme only requires that DNS publications be made by the Trusted 380 Domain, even when the sending domains and the Trusted Domain differ. 381 This approach eliminates a need to exchange private information thus 382 protecting the domain's integrity. Before TPA-LLD authorization is 383 deployed, the Trusted Domain should be assured by domains being 384 authorized that appropriate measures are in place to validate those 385 submitting messages and ensure the Federated Identity is protected. 387 Retaining validation and authorization for the From, Sender, and 388 List-ID header fields, and being able to ensure Third-party inclusion 389 of a Sender or List-ID header fields, enhances protections afforded 390 by message sorting. This protection reduces susceptibility to 391 deceptive look-alike phishing attempts. Use of subdomains that 392 assert less stringent practices might inadvertently combine with 393 those having more stringent practices when sorting is based upon 394 parent domains. Consistently using the same domain prevents possible 395 confusion that could be exploited to deceive recipients. 397 TPA-Label authorization will not ensure all possible spoofing is 398 prevented. However, by permitting broader use of strict alignment 399 practices, this should generally reduce the level of spoofing over 400 what might be otherwise allowed. Authorized third party messages 401 SHOULD NOT receive annotations that indicate the message contains 402 validated identities. The TPA-LLD scope SHOULD include the 'S' or 403 'L' scope where appropriate to allow recipients a means to isolate 404 and distinguish different message sources. 406 8. Evaluating the Third-Party Domain 408 A Trusted Domain deploying a TPA-Label Resource Record does so on a 409 trust basis. Reasons for deploying TPA-Label Resource Records might 410 be to allow deployment of more stringent DMARC records while also 411 utilizing Third-Party Services. 413 When an authorized Third Party domain does not employ DKIM or SPF or 414 does not include Authentication-Results header fields [RFC7001] or 415 perhaps [I-D.kucherawy-original-authres] or its "X-" version could 416 allow authorizations to be exploited. 418 While conceivably Domain Alignment might just rely on the content of 419 the Original-Authentication-Results header, whether to trust this, or 420 any other message content can not be based on the mere acceptance of 421 the message alone. Whether false content even effects message 422 acceptance would be difficult to determine. Only the Trusted Domain 423 is able to make this type of determination which they can then share 424 in their TPA-Label. 426 8.1. Third Party Authorization - Closed Mailing List Example 428 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 429 mailing list with a closed posting policy. The mailing list 430 redistributes email which breaks the Trusted Domain Alignment, and 431 the mailing list offers a means to validate the mailing list domain 432 and includes an Authentication-Results header field for posted 433 messages. The closed posting policy can be enforced by requiring 434 subscribers to validate control of their Author Addresses by 435 responding to encoded "pingback" email sent to these addresses. 437 Since the mailing list validates their domain as indicated in the 438 TPA-Label, and validates control of the posted message Author 439 Address, and includes Authentication-Results header fields, and 440 includes a List-ID header field, the referenced TPA-Label Resource 441 Record can include an 'L' scope value to stipulate that the Third- 442 Party Domain messages contain an authorized List-ID domain. 444 8.2. Third Party Authorization - Open Mailing List Example 446 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 447 mailing list with an open posting policy. The mailing list 448 redistributes email in a way that breaks Trusted Domain alignment, 449 does not post from an Author Address not in compliance with DMARC, 450 offers a means to validate the mailing list domain, and it includes 451 an Authentication-Results header field for posted messages. 453 Since the mailing list validates the domain as indicated in the TPA- 454 Label, and is configured to include Authentication-Results header 455 fields and possibly the Original-Authentication-Results 456 [I-D.kucherawy-original-authres], and includes a List-ID header 457 field, the referenced TPA-Label Resource Record can include an 'L' 458 scope value to stipulate the Third-Party Domain messages contain an 459 authorized List-ID domain. 461 8.3. Third Party Authorization Example - Sender Header Field 463 Trusted Domain "example.com" wishes to temporarily employ the service 464 agency "temp.example.org" to handle overflow secretarial support. 465 The agency "temp.example.org" sends email on behalf of the executive 466 staff of "example.com" and adds the Sender header field of 467 "secretary@temp.example.org" in the email. 469 Since "temp.example.org" only allows its own staff to email through 470 its server which adds "temp.example.org" DKIM signatures, a TPA-LLD 471 can include the "temp.example.org" domain with an 'S' and 'd' scope 472 to specifically authorize DKIM signed messages containing the Sender 473 header field, to help ensure these messages are not handled as 474 phishing attempts. 476 8.4. Services Lacking DKIM Signatures 478 8.4.1. Abuse and DSN Reporting 480 There is likely little interest for an otherwise uninvolved domain to 481 receive a massive number of bogus messages being returned as 482 feedback. Often the purpose of feedback is to discover compromised 483 systems or accounts actively being exploited in some manner. Unless 484 the Trusted Domain is confirmed as having handled or authorized the 485 handling of the message, only statistics and samples should be 486 reported to the associated Autonomous System [RFC1930], and perhaps 487 to the Trusted Domain when interest is expressed. 489 The 'd', 'e', 'h', 'm', and 't' scope options within the TPA-LLD 490 records allow the Trusted Domain to be associated through various 491 methods. In this case, appropriate DSN or abuse reporting to the 492 Trusted Domain is better assured as well. 494 8.4.2. Third Party Authorization Example - SMTP Host 496 Trusted Domain "example.com" makes use of invite services. This 497 service does not utilize DKIM, where the host name given by the EHLO 498 command is "invite.example.net". The Trusted Domain can authorize 499 the domain "invite.example.net" or "example.net" with the scope of 500 'e' to improve acceptance of messages that are sent on behalf of 501 "example.com" from this outbound server. 503 8.4.3. Third Party Authorization Example - Return Path 505 Trusted Domain "example.com" makes use of tell-a-friend services. 506 This service does not utilize DKIM with its own return path as 507 "customer@taf.example.net" in the SMTP exchange. The Trusted Domain 508 can authorize the domain "taf.example.net" with the scope of 'm' to 509 improve acceptance of messages that are sent on behalf of 510 "example.com" from this outbound server. 512 8.4.4. Use of Path Authorization 514 Those using validations related to 'e', 'h', 'm' scope options should 515 not authorize domains requiring more than an average number of 516 network transactions. Those implementing DMARC should also limit the 517 number of DNS transactions attempted, otherwise this could negatively 518 impact unrelated domains when evaluating path related validation. 520 Methods that create subsequent transactions based upon the macro 521 expansion of email-address local-parts should not be used. 522 Libraries that process SPF [RFC7208] record scripts may invoke a 523 large number of DNS transactions from cached records, and target 524 unrelated domains with queries modulated by the local-part 525 component through receiver macro expansion. 527 9. DNS Representation 529 The receiver obtains domain authorizations with a DNS query for an IN 530 class TXT TPA-Label Resource Record located below the 531 "_smtp._tpa." location. The TPA-Label itself is 532 generated by processing the domain in question, which normally 533 matches the DKIM signature's "d=" parameter. The Trusted Domain 534 provides authorization for other domains with the existence of a TPA- 535 Label TXT resource record. When a "tpa" tag value exists, it MUST 536 include the referenced domain before authorization is valid. This 537 represents an informal authorization on behalf of the Trusted Domain 538 which can be limited by the "scope" tag value for specific message 539 elements. 541 A Trusted Domain may wish to delegate the listing of Third-Party 542 Services to a different administrative domain. Ideally, this would 543 be accomplished by delegating the _tpa. zone to the 544 administrative entity handling publication of TPA-Label Resource 545 Records. This delegation could also be done unilaterally with a 546 DNAME [RFC6672] resource record published at _smtp._tpa.. 549 Character-strings contained within the TXT resource record are 550 concatenated into forming a single string. A character-string, as 551 defined in [RFC1035] Section 3.3 for resource records, is a single 552 length octet followed by that number of characters treated as binary 553 information. 555 The TPA-Label Resource Records should be located at these domains: 557 ._smtp._tpa.. 559 10. TPA-Label and Tag Syntax Definitions 561 Augmented BNF for Syntax Specifications: 563 asterisk = %x2A ; "*" 564 dash = %x2D ; "-" 565 dot = %x2E ; "." 566 underscore = %x5F ; "_" 567 ANY = asterisk dot ; "*." 568 dns-char = ALPHA / DIGIT / dash 569 id-prefix = ALPHA / DIGIT 570 label = id-prefix [*61dns-char id-prefix] 571 sldn = label dot label 572 base-char = (dns-char / underscore) 573 domain = *(label dot) sldn 575 FWS = ([*WSP CRLF] 1*WSP) ; omits RFC5322 obs-FWS 576 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 577 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 578 tag-name = ALPHA 0*ALNUMPUNC / "v" / "scope" / "tpa" 579 tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] 580 ; WSP and FWS prohibited at beginning and end 581 tval = 1*VALCHAR 582 VALCHAR = %x21-3A / %x3C-7E 583 ; EXCLAMATION to TILDE except SEMICOLON 584 ALNUMPUNC = ALPHA / DIGIT / "_" 586 11. TPA-Label Generation 588 The TPA-Label is generated by nesting functions as follows: 590 "base32" function is defined in [RFC4648]. 592 "sha1" function is defined in [FIPS.180-2.2002]. 594 "lcase" converts upper-case ALPHA characters to lower-case. 596 "tpa-domain" is normally the "d=" tag value defined in Section 3.5 597 of [RFC6376]. 599 (underscore) base32( sha1( lcase(tpa-domain))) 601 The TPA-Label is created from the hash value returned by the "sha1" 602 function of the tpa-domain expressed in lower case ASCII. Any 603 terminating period is not included with the tpa-domain, as indicated 604 by the ABNF definition. 606 Note: No newline character, 0x0A, is to be appended to the end of 607 the domain name, as might occur with the command line generation 608 of sha1 values. For example, these command line appended newlines 609 can be avoided by using the 'echo -n" option. 611 The label encoding process inputs the hash as a byte stream of four 612 40-bit data blocks where each data block outputs 8 encoded 613 characters. Proceeding from left to right, a 40-bit input group is 614 formed by concatenating 5 bytes. The 40-bit input is then treated as 615 8 concatenated 5-bit groups, each of which is translated into a 616 single digit of the base32 alphabet. The bit stream is ordered with 617 the most-significant-bit first, being the high-order bit of the first 618 byte. The entire output is then concatenated first to last, left to 619 right, into 32 characters prefixed with an underscore. 621 12. TPA-Label TXT Resource Record Structure 623 Every TPA-Label TXT resource record MUST start with the version tag, 624 so the first six characters of the record are lowercase "v=tpa1", 625 TPA-Label syntax descriptions for additional tags follow the tag- 626 value syntax described in Section 3.2 of [RFC6376]. Unrecognized 627 tags and tags with illegal values MUST be ignored. In the ABNF 628 below, the WSP token is inherited from [RFC5322]. The ALPHA and 629 DIGIT tokens are imported from [RFC5234]. 631 The tags used in TPA-Label Resource Records are as follows: 633 +------------+--------------------------------------+ 634 | Tag | Function | 635 +------------+--------------------------------------+ 636 | v | Label Version (version-tag) | 637 | scope | Authorization Scope List (scope-tag) | 638 | tpa | Authorized Domains List (tpa-tag) | 639 +------------+--------------------------------------+ 640 TPA-Label Tags 642 +--------------+----------------------+--------------------------+ 643 | scope values | Field or Parameter | Method | 644 +--------------+----------------------+--------------------------+ 645 | L | List-ID Header Field | Match List-ID Identifier | 646 | S | Sender Header Field | Match Address Domain | 647 | d | DKIM Signature | Match Signature Domain | 648 | e | SMTP Hostname | Resolve Hostname IP Addr | 649 | h | SMTP Hostname | Pass SPF with Hostname | 650 | m | MailFrom | Pass SPF with MailFrom | 651 | t | SMTP Hostname | Cert of Hostname | 652 +--------------+----------------------+--------------------------+ 654 TPA-Label Scope Values 656 13. TPA-Label Resource Record Definition 658 Tags in the TPA-Label Resourse Record are shown below. The ver-tag 659 MUST be present as the left most tag. Unrecognized tags MUST be 660 ignored. 662 TPA-Label Resource Record Definition 663 tpalabelrr = v-tag [";"] 0*( 1*(WSP) tag-list) ] 665 14. TPA-Label Resource Record Version 667 Label Version (Required). This tag defined the version of the TPA- 668 Label. Only recognized scope values offer any form of DMARC 669 authorization. 671 "scope" tag 672 v-tag = %76.3d.74.70.61.31 ; "v=tpa1" 674 15. TPA-Label Resource Record Scope Syntax 676 Authorization Scope List (Optional). This tag defines a list of 677 scoping assertions for various email-address locations within the 678 message. Only recognized scope values offer any form of DMARC 679 authorization. 681 "scope" tag 682 as_val = "L" / "S" / "d" / "e" / "h" / "m" / "t" 683 as-list = %x73.63.6f.70.65 *WSP "=" [ as_val 0*( 1*(WSP) as_val )] 685 15.1. Authorized Validated Domains 686 Authorized validated domain list. (optional) This tag, when present, 687 MUST repeat all or portions of the domain encoded within the TPA- 688 Label Resource Record. This option ensures the proper handling of 689 possible hash collisions. When a domain is prefixed with the "*." 690 ANY label, then all subdomains of this domain are to be considered 691 included within the list. When the 'tpa' tag is not present or has 692 no value, it should be assumed to compare with the domain used to 693 generate the TPA-Label. The purpose of the ANY label is to reduce 694 the size of the resource records. Containing the entire string to 695 confirm hostnames or List-ID content is unnecessary. The hash label 696 must still be an exact match of the domain authorized. 698 Use of the ANY label is not intended to support wildcards for 699 referencing hash labels. No wildcard labels are to be used below the 700 "_tpa." label to access DNS resources. 702 "tpa" tag 703 ad_val = [ANY] domain 704 ad-list = %x74.70.61 *WSP "=" [ ad_val 0*( 1*(WSP) ad_val )] 706 15.2. Header Dependent Authorizations 708 15.2.1. List-ID Header Field 710 The "L" scope asserts that authorization is valid only when a List-ID 711 identifier of the List-ID header field [RFC2919] contains a domain 712 that is within a domain listed in the TPA-LLD "tpa" tag. 714 The syntax of the List-Id header field is as follows: 715 list-id-header = "List-ID:" [phrase] "<"identifier">"CRLF 717 15.2.2. Sender Header Field 719 The "S" scope asserts that authorization is valid only when the 720 domain in the Sender header field is within the TPA-LLD. 722 15.2.3. Combined 'L' or 'S' Scopes 724 When combined, the scopes 'L' and 'S' require that either a List-ID 725 identifier of the List-ID header field or the Sender header field 726 must contain a domain within the TPA-LLD for the authorization to be 727 valid. 729 15.3. DKIM signed domain 731 15.3.1. DKIM signed 732 The "d" scope asserts that messages carrying the Trusted Domain 733 within the From header field are authorized to be signed by the TPA- 734 LLD. 736 15.4. SMTP Host domains 738 The "e" scope asserts that host names given in [RFC5321] EHLO or HELO 739 commands within TPA-LLD is authorized when the hostname resolves the 740 server's IP address. 742 15.5. SMTP Host domains 744 The "h" scope asserts that host names given in [RFC5321] EHLO or HELO 745 commands within TPA-LLD is authorized only when this hostname 746 submitted to an SPF [RFC7208] process returns pass. 748 15.6. MailFrom Parameter 750 The "m" scope asserts that an email-address domain in the [RFC5321] 751 MAIL command within a TPA-LLD is authorized only when this email- 752 address submitted to an SPF [RFC7208] process returns pass. 754 15.7. SMTP Host domains 756 The "t" scope asserts that host names given in [RFC5321] EHLO command 757 after [RFC3207] negotiation where the Cert DNS-ID domain is within 758 TPA-LLD is authorized. It will also be interesting to see whether 759 [I-D.ietf-dane-smtp-with-dane] establishes a way to authenticate 760 sending domains. 762 Note to RFC Editor: Remove this comment before publishing. 763 Currently, no general practice employs certificates to confirm the 764 domain of the client initiating a connection. This may be needed 765 for clients within IPv6 IP address space where tunneling, carrier 766 grade NATs, and rapid space assignment without any practical 767 reverse mapping reduces the effectiveness of IP address based 768 reputations. 769 There is an existing TLS option for SMTP and an ongoing effort to 770 standardize automated server confirmation. It might be possible 771 to leverage this effort to establish practices used at the client. 772 See conversations defined in [RFC4954] Section 4. For information 773 related to ongoing server related efforts see: 774 [RFC6125] and [RFC6698] 776 16. TPA-Label Resource Record Query Transactions 778 The discovery of TPA-Label Resource Records need not be subsequent to 779 the discovery of the DMARC record. However, when no DMARC record is 780 discovered which includes the tag value of "tpa", the verifier MAY 781 assume no TPA-Label Resource Records have been published. Otherwise, 782 when there is no Trusted Domain validation, the discovery of TPA- 783 Label Resource Records should be attempted. 785 17. TPA-Label Resource Record Compliance Extension 787 The signing practice compliance assessment of Third Party Signatures 788 is a discretionary operation performed by the verifier. For messages 789 that do not have valid Trusted Domain alignment, a verifier may 790 decide to assess compliance for Third Party messages when there is a 791 DMARC tag of "tpa". Elements then referenced in the TPA-Label scope 792 values of "d", "m", "e", "h", "t" are to be checked in their listed 793 succession. One of the following sets of conditions MUST be met for 794 the result to be considered a pass: 796 For Third Party DKIM signatures, the following represents the set of 797 conditions to be checked: 799 o The Third Party Signature MUST validate according to [RFC6376]. 800 o A TXT resource record, referenced by a TPA-Label created by the 801 DKIM signature "d=" tag, MUST exist in DNS. 802 o The discovered TPA-Label Resource Record structure MUST be valid. 803 o The domain that created the TPA-Label MUST be within the TPA-LLD. 804 o Where a scope of 'd' is specified, the Trusted Domain MUST have an 805 authorized DKIM signature. 806 o Where a scope of 'L' or 'S' is specified, a List-ID identifier in 807 the List-ID header field or a Sender header field MUST contain a 808 domain within the TPA-LLD. This provides Third-Party services a 809 reason to ensure their outbound messages do not spoof these 810 associated header fields. 812 For non-DKIM validations, the TXT record discovery process continues 813 until a TPA-Label Resource Record structure is found where: 815 One of the three possible TXT resource records is checked in their 816 listed succession. Each would be referenced by an 'h' or 'e' or 't' 817 related domain given by [RFC5321] EHLO or HELO command, this domain 818 with left-most label omitted, or by an 'm' related email-address 819 domain within the [RFC5321] MAIL command. 821 o The discovered TPA-Label Resource Record Structure is valid. 823 o The domain that created the TPA-Label is within the TPA-LLD. 824 o The domain that created the TPA-Label corresponds with a listed 825 scope of 'e', 'h' or 'm' or 't'. 826 o Where a scope of 'L' or 'S' is specified, either the domain in 827 List-ID given by [RFC2919] in the List-ID header field is within 828 the TPA-LLD, or a Sender header field contains a domain within the 829 TPA-LLD respectively. 830 o Once these four conditions have been met, for 'h' or 'm' scopes 831 the domain MUST be confirmed by submitting the domain to an SPF 832 process that then returns pass. The 'e' scope MUST be confirmed 833 by a forward DNS reference that resolves the address of the SMTP 834 client. The 't' scope MUST be confirmed by the DNS-ID in the 835 client certificate. 837 When the TPA-Label Resource Record can not be retrieved due to some 838 error that is likely transient in nature, such as "SERVFAIL" for 839 example, the result of the TPA-Label Resource Record compliance 840 assessment is "temperror". 842 When the TPA-Label Resource Record retrieval returns a DNS "NOERROR", 843 but not with a single record, the result of the TPA-Label Resource 844 Record compliance assessment is "permerror". 846 When the TPA-Label Resource Record can not be retrieved with a DNS 847 "NXDOMAIN" response, the result of the TPA-Label Resource Record 848 compliance assessment is "nxdomain". 850 18. Privacy Considerations 852 As with other authorization schemes that utilize DNS, relationships 853 are publicly revealed. This is the nature of SPF authorization which 854 reveals first party services being used. A TPA-Label on the other 855 hand can resolve a hash obscured Third-Party Service. Unlike SPF, a 856 TPA-Label does not include any user identity related parameters and 857 does not reveal any users specific relationships. In addition, these 858 relationships are accessed with a hash of the entire domain. Use of 859 a few random subdomains can inhibit discovery of these relationships. 860 However, the low latency of DNS means resource records can not be 861 assumed to remain secret. 863 Even so, disclosures of Third-Party Services might be justified by 864 dissuading malefactors who have compromised the Trusted Domain and 865 then are able to subsequently spoof the discovered personal 866 relationships. Such spoofing might be seen as causing getter harm 867 then public knowledge of possible Third-Party Services used by the 868 Trusted Domain's users. 870 Overhead associated with managing a "_tpa." zone is fairly small and 871 is offset by the squelching of DMARC feedback generation and the 872 remediation of a loss of legitimate messages. Alternatives to TPA- 873 Labels are likely to be the dissemination of plaintext lists of 874 domains known to cause alignment failures, although operating in full 875 compliance with SMTP protocols and practices. 877 19. IANA Considerations 879 19.1. Moving RFC6541 to historic 881 This document is seeking to replace [RFC6541] and to move it to 882 historic. 884 19.2. TPA-Label (TPA-LLD) Parameters 886 To accommodate the extensions to [RFC7001] needs the following 887 elements to be added: 889 +------+-----------------+ 890 | Type | Reference | 891 +------+-----------------+ 892 | tpa | (this document) | 893 +------+-----------------+ 895 TPA-Label Resource Record validation Method 897 19.3. Email Authentication Method Registry 899 To accommodate the method derived from TPA-Label Resource Record 900 processing, the IANA Registry "Email Authentication Method" defined 901 by Section 6.2 of [RFC7001] needs the following elements to be added: 903 +---------+-----------+--------+----------+-------------------------+ 904 | Method | Defined | ptype | property | value | 905 +---------+-----------+--------+----------+-------------------------+ 906 | tpa-lld | (this | domain | 3p-dom | Domain evaluated. The | 907 | | document) | | | method results from | 908 | | | | | [RFC7001] should also | 909 | | | | | be included in a | 910 | | | | | Authenticated Results | 911 | | | | | header field. | 912 | | | | scope | value of scope | 913 | | | | | (Section 19.6) tag. | 914 | | | | | (When 'scope' contains | 915 | | | | | 'e', 'h' or 'm', the | 916 | | | | | iprev [RFC7001] | 917 | | | | | (Section 3) method | 918 | | | | | results should also be | 919 | | | | | included in the | 920 | | | | | Authenticated-Results | 921 | | | | | header field to capture | 922 | | | | | the SMTP client IP | 923 | | | | | address. | 924 | | | | ca-scope | The scopes | 925 | | | | | (Section 19.6) with a | 926 | | | | | compliance assessment | 927 | | | | | as pass | 928 | | | | tpa | Value of tpa | 929 | | | | | (Section 15.1) tag at | 930 | | | | | time of compliance | 931 | | | | | assessment | 932 +---------+-----------+--------+----------+-------------------------+ 934 TPA-Label Resource Record validation Method 936 19.4. Email Authentication Result Names Registry 938 To accommodate the results derived from TPA-Label Resource Record 939 processing, the IANA Registry "Email Authentication Method" defined 940 by Section 6.3 of [RFC7001] needs the following elements added: 942 +----------+----------+---------------------------------------------+ 943 | code | method | meaning | 944 +----------+----------+---------------------------------------------+ 945 | none | tpa-lld | No TPA-Label was published | 946 | pass | tpa-lld | Section 17 | 947 | tempfail | tpa-lld | Section 17 | 948 | permfail | tpa-lld | Section 17 | 949 | hdrfail | tpa-lld | The TPA-Label Resource Record scope values | 950 | | | of "S" or "L" failed to match. | 951 | nxdomain | tpa-lld | When obtaining the TPA-Label Resource | 952 | | | Record, DNS indicated this domain does not | 953 | | | exist. | 954 +----------+----------+---------------------------------------------+ 956 TPA-Label Resource Record complaince assessment Results 958 19.5. Third Party Authorizations Labels Registry 960 Names of tags that are valid in TPA-Label Resource Records with the 961 exception of experimental tags Section 12 MUST be registered in this 962 created IANA registry. 964 New entries are assigned only for values that have been documented in 965 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 966 [RFC5226]. 968 Each tag registered must correspond to a definition. 970 The initial set of values for this registry is: 972 +----------+--------------+-----------------------------------------+ 973 | tag | defined | definition | 974 +----------+--------------+-----------------------------------------+ 975 | v | Section 12 | Label Version | 976 | scope | Section 15 | Section 19.6 | 977 | tpa | Section 15.1 | List of Authorized Domains or | 978 | | | Identifiers | 979 +----------+--------------+-----------------------------------------+ 981 TPA-Label Resource Record compliance assessment Results 983 19.6. Third Party Authorizations Scope Registry 984 Values that correspond to Section 15 MUST be registered in this 985 created registry: 987 New entries are assigned only for values that have been documented in 988 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 989 [RFC5226]. 991 Each value registered must correspond to a definition. 993 The initial set of values for this registry is: 995 +------------+----------------+ 996 | value | defined | 997 +------------+----------------+ 998 | L | Section 15.2.1 | 999 | S | Section 15.2.2 | 1000 | d | Section 15.3 | 1001 | h | Section 15.5 | 1002 | e | Section 15.4 | 1003 | m | Section 15.6 | 1004 | t | Section 15.7 | 1005 +------------+----------------+ 1007 TPA-Label Resource Record compliance assessment Results 1009 20. Security Considerations 1011 This draft extends Domain Alignment validation practices that depend 1012 on DKIM [RFC6376] or SPF [RFC7208]. Most related security matters 1013 are discussed in those specifications. Additional considerations are 1014 also included in [RFC6377]. Security considerations for the TPA-LLD 1015 scheme are mostly related to attempts on the part of malefactors to 1016 falsely represent themselves as others, often in an attempt to 1017 defraud either the recipient or the alleged originator. Some 1018 receivers mistakenly bypass validation of the [RFC5322] header fields 1019 because a signature from a Trusted Domain had been confirmed as 1020 perhaps suggested in [RFC5863]. Do not omit the validation of header 1021 fields unless the message is not accepted for other reasons. 1023 Additional security considerations regarding DKIM signing practices 1024 may be found in the DKIM threat analysis [RFC4686]. 1026 20.1. Benefits to Recipients 1028 The verifier, after validating a Federated Domain, will have 1029 significantly greater confidence in the Third-Party, than when no 1030 TPA-Label Resource Record is obtained. This enhanced confidence may, 1031 at the recipients' discretion, cause a message to be delivered to the 1032 recipient with less stringent assessments. 1034 20.2. Risks to Recipients 1036 The decisions a recipient makes in regard to message filtering based 1037 on TPA-Label Resource Records are likely to depend on the system 1038 integrity of the Third Party with respect to the validation methods 1039 determined by authorization scope labels. When the 'e', 'h', or 'm' 1040 scoped domain is not confirmed, or the Third-Party Domain does not 1041 validate the submitter, there is a risk of accepting potentially 1042 spoofed messages. Authentication-Results header fields then play an 1043 important role when there is no out-of-band validations confirming 1044 the submitter. Without proper Authentication-Results handling by the 1045 Third-Party, there is also risk of accepting potentially spoofed 1046 messages. 1048 With the TPA-Label specification, third party validation provides 1049 verifiable value. Implementers should consider the possibility a 1050 malefactor will send a message having a large number of valid DKIM 1051 Signatures. Verifying all the signatures may consume a large amount 1052 of processing resources. As such, it might be worth checking for the 1053 existence of a TPA-Label Resource Record first to minimize network 1054 amplification concerns. Section 16 describes a quick check to see if 1055 TPA-Label Resource Records may exist. Additionally, validating DKIM 1056 signatures and obtaining related resource records might be limited to 1057 known trustworthy domains. 1059 Services that depend only upon path authorizations might permit the 1060 Trusted Domain to be spoofed and yet obtain acceptance. During such 1061 events, the Trusted Domain might need to retract its authorization 1062 from the service. For this reason, path related validation based on 1063 IP addresses should only be used as a carefully monitored interim 1064 solution. 1066 20.3. Benefits to Trusted Domains 1068 TPA-Label Resource Records can replace domain delegations, selector/ 1069 key record mirroring, or key exchanges. A significant number of 1070 details are associated with selector/key records. These details 1071 include user limitations, suitable services, key resource record's 1072 Time-To-Live, revocation and update procedures, and how the DKIM 1073 Signature header field's 'i=' semantics are to be applied. In 1074 addition, services that depend upon DKIM keys are better secured by 1075 not delegating these DKIM keys, where instead the TPA-LLD scheme 1076 allows Trusted Domains an ability to limit the scope of their 1077 authorizations, while also not being mistaken for having validated 1078 the entity submitting the message. 1080 TPA-Label Resource Records convey which domains are authoritative 1081 even when they are not the Trusted Domain. However, Authorized 1082 Domains are unable to utilize the DKIM signature's 'i=' semantics to 1083 directly assert which identifiers on whose behalf a signature was 1084 added. As such, no domain should be authorized unless it is trusted 1085 to ensure the Federated Identity of an email undergoes validation 1086 that offers acceptable protections for the Trusted Domain. For 1087 example, such validation might ensure submitting entities have 1088 demonstrated receipt of "pingback" messages sent to the Federated 1089 Identity (Author's address) contained within the messages being 1090 signed. 1092 By deploying TPA-Label Resource Records, Trusted Domains benefit when 1093 recipients assess signing practice compliance by using the TPA-LLD 1094 scheme. These recipients will be less likely to drop the Trusted 1095 Domain's genuine messages, whenever the Trusted Domain attempts to 1096 restrict acceptance. Restricting acceptance of non-compliant 1097 messages is the basic motivation for publishing DMARC records. In 1098 addition, recipients are more likely to validate signatures by an 1099 Authorized Domain. 1101 Broader use of strict DMARC alignment assertions provides a greater 1102 likelihood of being able to eliminate a broader range of non- 1103 compliant messages, in addition to improving acceptance from 1104 authorized sources. TPA-Labels also allow Trusted Domains to control 1105 message Sender and List-ID attributes, to exclude problematic 1106 validation methods or include others as they become available. 1108 Trusted Domains having good reputations might extend limited 1109 compliance assessment resources to otherwise unknown domains or SMTP 1110 Clients that are referenced by their TPA-LLD. 1112 20.4. Risks to Trusted Domains 1114 As indicated in Section 8, it is ultimately an issue of trusting the 1115 Third Party Domain to do the right thing and not generate, or allow 1116 others to generate, messages that falsely appear to be from the 1117 Trusted Domain. The validation methods in place for different email 1118 elements need to be carefully reflected in the scope of the TPA-LLD. 1120 Authorization of mailing lists with TPA-LLD could cause a loss of 1121 confidentiality in mailing list participation by the Trusted Domain. 1122 This might help malefactors deduce which subscription related email 1123 the Trusted Domain may receive. Because of the hashing function in 1124 generating the TPA-Label, anyone wishing to discover which domains 1125 are being authorized, has to probe each TPA-Label based on the exact 1126 domain. In addition, service organizations or community groups are 1127 able to share comprehensive lists. Such possible sharing means even 1128 though a domain has been authorized, that in itself does not mean the 1129 Trusted Domain is exchanging messages with the Authorized Domain. 1131 20.5. Benefits to Third Party Signers 1133 Third Party Signers benefit by allowing those using their service, 1134 the autonomy to authorize their service without needing to exchange 1135 DKIM key related details. This is particularly useful for mailing 1136 lists. 1138 20.6. Risks caused by Third Party Signers 1140 As mentioned before, Authorized Third Party Signers need to validate 1141 messages from Trusted Domains. This validation provides a safety 1142 mechanism for the Trusted Domain and their recipients. The Third 1143 Party may not be aware of the validation value or the message 1144 elements involved, and as a result make changes without understanding 1145 the impact this may have on Trusted Domains and their recipients. 1146 For example, the Third Party might stop DKIM signing or stop applying 1147 Authentication-Results header fields. The unexpected exposure that 1148 this might enable could allow abuse and prove detrimental for both 1149 the Trusted Domain and their recipients. 1151 20.7. SHA-1 Collisions 1153 The use of the SHA-1 hash algorithm does not represent a security 1154 concern. The hash simply ensures a deterministic domain-name size is 1155 achieved. Unexpected collisions can be detected and handled by using 1156 the extended TPA-Label Resource Record "tpa=" option. The use of 1157 TPA-Label Resource Records without the TPA-Label "tpa=" options does 1158 present an opportunity for an adversary to attempt to find a hash 1159 collision. Message spoofing outside the realm of DKIM protection is 1160 likely easier to achieve than finding hash collisions. There is 1161 minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains has 1162 less than a 0.1 percent risk of any two domain labels colliding. 1164 20.8. DNS Limits 1166 Use of the TPA-Label Resource Records, rather than simply listing the 1167 Authorized Domain, ensures the DNS record size is independent of the 1168 Third Party Domain. The typical domain name size has been steadily 1169 increasing. This increase has been caused by domain names that 1170 encode international character sets. Perhaps, soon there will be a 1171 further increase spurred by an expanse of TLDs having larger 1172 international labels. 1174 The maximum domain name size allowed, per [RFC1034] Section 3, is 255 1175 bytes (or octets). Each label has a byte for its length. Every 1176 domain name adds an additional byte by having a right-most label that 1177 represents the root "." signified as a zero length label. A labeling 1178 scheme that combines together a listed domain with the publishing 1179 domain separated by some label for this convention, reduces the 1180 maximal domain name in half, where the convention label reduces this 1181 further. 1183 If "_smtp._tpa." were used as the convention label with a simple 1184 listing method, the maximum domain name size this supports would be 1185 128 bytes. The suffix for TPA-Labels is "_smtp._tpa." which consumes 1186 11 bytes. The TPA-Label itself consumes 34 bytes. A domain that 1187 publishes the TPA-Labels in its domain would then have 122 bytes 1188 available for their Trusted Domain. This permits the authorization 1189 of any domain having a valid length with a deterministic amount of 1190 space available for resource records. 1192 Normally, DNS messages should not exceed 512 bytes as per Section 1193 2.3.4 of [RFC1035]. Using TPA-Label Resource Records in the DNS, as 1194 described by this document, consumes a consistent 50 bytes, in 1195 addition to the domain name publishing the TPA-Labels. With this 1196 being constant, a limit can be determined as a constraint to resource 1197 record size, to ensure a response does not exceed the maximum DNS 1198 message size. DNS servers that add additional resource records, for 1199 nameservers as an example, will further reduce available resource 1200 record capacity. Domains publishing TPA-Labels exceeding the DNS 1201 message limit will need to rely on recipients using TCP for DNS 1202 retrieval, or EDNS0 [RFC6891] for extended DNS lengths. 1204 21. Acknowledgements 1206 Jeff MacDonald, Michael Deutschmann, Frank Ellermann, Murray 1207 Kucherawy, Wietse Venema, Alessandro Vesely, and John Leslie. 1209 22. References 1211 22.1. Normative References 1213 [FIPS.180-2.2002] 1214 National Institute of Standards and Technology, "Secure 1215 Hash Standard", FIPS PUB 180-2, August 2002, . 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, March 1997. 1221 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1222 and Namespace for the Identification of Mailing Lists", 1223 RFC 2919, March 2001. 1225 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1226 Transport Layer Security", RFC 3207, February 2002. 1228 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1229 Encodings", RFC 4648, October 2006. 1231 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1232 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1234 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1235 October 2008. 1237 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1238 October 2008. 1240 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1241 July 2009. 1243 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1244 Verification of Domain-Based Application Service Identity 1245 within Internet Public Key Infrastructure Using X.509 1246 (PKIX) Certificates in the Context of Transport Layer 1247 Security (TLS)", RFC 6125, March 2011. 1249 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1250 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1251 September 2011. 1253 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1254 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 1256 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 1257 Message Authentication Status", RFC 7001, September 2013. 1259 22.2. Informative References 1261 [I-D.ietf-dane-smtp-with-dane] 1262 Dukhovni, V. and W. Hardaker, "SMTP security via 1263 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 1264 (work in progress), May 2014. 1266 [I-D.kucherawy-dmarc-base] 1267 Kucherawy, M. and E. Zwicky, "Domain-based Message 1268 Authentication, Reporting and Conformance (DMARC)", 1269 draft-kucherawy-dmarc-base-04 (work in progress), 1270 April 2014. 1272 [I-D.kucherawy-original-authres] 1273 Chew, M. and M. Kucherawy, "Original-Authentication- 1274 Results Header Field", draft-kucherawy-original-authres-00 1275 (work in progress), February 2012. 1277 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1278 STD 13, RFC 1034, November 1987. 1280 [RFC1035] Mockapetris, P., "Domain names - implementation and 1281 specification", STD 13, RFC 1035, November 1987. 1283 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1284 selection, and registration of an Autonomous System (AS)", 1285 BCP 6, RFC 1930, March 1996. 1287 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1288 Identified Mail (DKIM)", RFC 4686, September 2006. 1290 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1291 for Authentication", RFC 4954, July 2007. 1293 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1294 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1295 May 2008. 1297 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 1298 Reference", RFC 5518, April 2009. 1300 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1301 "DomainKeys Identified Mail (DKIM) Development, 1302 Deployment, and Operations", RFC 5863, May 2010. 1304 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1305 Mailing Lists", BCP 167, RFC 6377, September 2011. 1307 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 1308 Authorized Third-Party Signatures", RFC 6541, 1309 February 2012. 1311 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1312 DNS", RFC 6672, June 2012. 1314 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1315 of Named Entities (DANE) Transport Layer Security (TLS) 1316 Protocol: TLSA", RFC 6698, August 2012. 1318 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1319 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1320 April 2014. 1322 Appendix A. DNS Example of TPA-Label Resource Record placement 1324 #### 1325 # Practices for Example.com email domain using example.com, isp.com, 1326 # and example.com.isp.com as signing domains. 1327 #### 1329 #### 5322.From authorization for 3P domains #### 1331 ## "isp.com" TPA-Label Resource Record ## 1332 _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com. IN TXT 1333 "v=tpa1 tpa=isp.com; scope=d;" 1335 #### 5322.Sender/List-ID authorization for 3P domains #### 1337 ## "example.com.isp.com" TPA-Label Resource Record ## 1338 _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._smtp._tpa.example.com. IN TXT 1339 "v=tpa1 tpa=*.isp.com; scope=d L S;" 1341 Appendix B. C code for label generation 1343 The following utility can be compiled as TPA-Label.c using the 1344 following: 1346 gcc -lcrypto TPA-Label.c -o TPA-Label 1348 1349 /* 1350 * TPA-Label generation utility 1351 * Copyright (c) 2010 IETF Trust and the persons identified as the 1352 * document authors. All rights reserved. 1353 * 1354 * This document is subject to BCP 78 and the IETF Trust's Legal 1355 * Provisions Relating to IETF Documents 1356 * (http://trustee.ietf.org/license-info) in effect on the date of 1357 * publication of this document. Please review these documents 1358 * carefully, as they describe your rights and restrictions with respect 1359 * to this document. Code Components extracted from this document must 1360 * include Simplified BSD License text as described in Section 4.e of 1361 * the Trust Legal Provisions and are provided without warranty as 1362 * described in the Simplified BSD License. 1363 * 1364 * This document and the information contained herein are provided on an 1365 * "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1366 * OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1367 * THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1368 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1369 * THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1370 * WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1371 */ 1372 #include 1373 #include 1374 #include 1375 #include 1376 #include 1377 #include 1378 #include 1379 #include 1380 #include 1381 #include 1382 #include 1384 #define TPA_LABEL_VERSION 102 1385 #define MAX_DOMAIN_NAME 256 1386 #define MAX_FILE_NAME 1024 1388 static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; 1389 static char sign_on[] = 1390 {"%s v%d.%02d Copyright (C) (2014) The IETF Trust\n"}; 1391 char err_cmd[] =\ 1392 "ERR: Command error with [%s]\n"; 1393 char use_txt[]=\ 1394 "Usage: TPA-Label [-i domain_input_file] [-o label_output_file][-v]\n"; 1395 char help_txt[]=\ 1396 "The options are as follows:\n"\ 1397 "-i domain name input. Defaults to stdin. Removes trailing '.'\n"\ 1398 "-o TPA-Label output. Defaults to stdout.\n"\ 1399 "-v Specifies Verbose Mode.\n\n"; 1401 static void usage(void); 1402 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1404 static void 1405 usage(void) 1406 { 1407 (void) fprintf(stderr, "\n%s%s", use_txt, help_txt); 1408 exit(1); 1409 } 1410 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1412 int 1413 main (int argc, char * argv[]) 1414 { 1415 int ret_val, in_mode, out_mode, verbose, done, i, j, k; 1416 char ch; 1417 unsigned int len; 1418 unsigned long b_5; 1419 char in_fn[MAX_FILE_NAME], out_fn[MAX_FILE_NAME]; 1420 unsigned char in_buf[MAX_DOMAIN_NAME + 2]; 1421 unsigned char sha_res[20], tpa_label[33]; 1422 FILE *in_file, *out_file; 1424 ret_val = in_mode = out_mode = verbose = done = 0; 1425 len = 0; 1427 while ((ch = getopt(argc, argv, "i:o:v")) != -1) 1428 { 1429 switch (ch) 1430 { 1431 case 'i': 1432 in_mode = 1; /* input from file */ 1433 (void) strncpy(in_fn, optarg, sizeof(in_fn)); 1434 in_fn[sizeof(in_fn) - 1] = '\0'; 1435 break; 1436 case 'o': 1438 out_mode = 1; /* out to file */ 1439 (void) strncpy(out_fn, optarg, sizeof(out_fn)); 1440 out_fn[sizeof(out_fn) - 1] = '\0'; 1441 break; 1442 case 'v': 1443 verbose = 1; 1444 break; 1445 case '?': 1446 default: 1447 (void) usage(); 1448 break; 1449 } 1450 }; 1452 if (in_mode) 1453 { 1454 if ((in_file = fopen(in_fn, "r")) == NULL) 1455 { 1456 (void) fprintf(stderr, 1457 "ERR: Error opening [%s] input file.\n", 1458 in_fn); 1459 exit(2); 1460 } 1461 } 1462 else 1463 { 1464 in_file = stdin; 1465 } 1467 if (out_mode) 1468 { 1469 if ((out_file = fopen(out_fn, "w")) == NULL) 1470 { 1471 (void) fprintf(stderr, 1472 "ERR: Error opening [%s] output file.\n", 1473 out_fn); 1474 exit(3); 1475 } 1476 } 1477 else 1478 { 1479 out_file = stdout; 1480 } 1482 if (out_mode && verbose) 1483 { 1484 (void) printf(sign_on, "TPA-Label utility", 1485 TPA_LABEL_VERSION / 100, 1486 TPA_LABEL_VERSION % 100); 1487 } 1489 for (i = 0; i < MAX_DOMAIN_NAME && !done; i++) 1490 { 1491 if ((ch = fgetc(in_file)) == EOF) 1492 { 1493 ch = 0; 1494 } 1495 else if (ch == '\n' || ch == '\r') 1496 { 1497 ch = 0; 1498 } 1500 in_buf[i] = tolower(ch); 1502 if (ch == 0) 1503 { 1504 len = i; /* string length */ 1505 done = 1; 1506 } 1507 } 1509 if (!done) 1510 { 1511 (void) fprintf(stderr, "ERR: Domain name too long.\n"); 1512 exit (4); 1513 } 1515 if (len && in_buf[len - 1] == '.') /* remove any trailing "." */ 1516 { 1517 len--; 1518 in_buf[len] = 0; /* replace trailing "." with 0 */ 1519 } 1521 in_buf[len] = 0; /* terminate string */ 1523 if (len < 2) 1524 { 1525 (void) 1526 fprintf(stderr, 1527 "ERR: Domain name [%s] too short with %d length.\n", 1528 in_buf, 1529 len); 1530 exit (5); 1531 } 1533 SHA1(in_buf, len, sha_res); 1534 if (verbose) 1535 { 1536 printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len); 1538 for (i = 0; i < 20; i++) 1539 { 1540 printf("%02x", sha_res[i]); 1541 } 1542 printf("\nTPA-Label 5 bit intervals left to right.\n"); 1543 } 1545 /* process sha1 results 4 times by 40 bits (160 bits) */ 1546 for (i = 0, j = 0; i < 4 ; i++) 1547 { 1548 b_5 = (unsigned long long) sha_res[(i * 5)] << 32; 1549 b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24; 1550 b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16; 1551 b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8; 1552 b_5 |= (unsigned long long) sha_res[(i * 5) + 4]; 1554 if (verbose) 1555 { 1556 printf(" {%010llX}->", b_5); 1557 } 1559 for (k = 35; k >= 0; k-= 5, j++) /* convert 40 bits (5x8) */ 1560 { 1561 tpa_label[j] = base32[(b_5 >> k) & 0x1F]; 1563 if (verbose) 1564 { 1565 printf(" %02X:%c", 1566 (unsigned int)(b_5 >> k) & 0x1F, 1567 tpa_label[j]); 1568 } 1569 } 1570 if (verbose) 1571 { 1572 printf ("\n"); 1573 } 1574 } 1575 if (verbose) 1576 { 1577 printf("\n"); 1578 } 1579 tpa_label[j] = 0; /* terminate label string */ 1580 fprintf(out_file, "_%s", tpa_label); 1581 printf("\n"); 1582 /* close */ 1583 if (out_mode) 1584 { 1585 if (fclose (out_file) != 0) 1586 { 1587 (void) fprintf(stderr, 1588 "ERR: Unable to close %s output file.\n", 1589 out_fn); 1590 ret_val = 6; 1591 } 1592 } 1593 if (in_mode) 1594 { 1595 if (fclose (in_file) != 0) 1596 { 1597 (void) fprintf(stderr, 1598 "ERR: Unable to close %s input file.\n", 1599 in_fn); 1600 ret_val = 7; 1601 } 1602 } 1603 return (ret_val); 1604 } 1605 1607 Appendix C. History of Prior Efforts 1609 To withstand asserting strict alignment practices, a scheme was 1610 devised that transferred the burden of a resulting disruption from 1611 receivers back to the Trusted Domains making the stringent requests. 1612 As such, a method to authorize other validated domains to establish 1613 informally Federated Third-Party Services, such as mailing-lists was 1614 developed. This initial scheme was then modified and proposed by 1615 ATPS [RFC6541]. Unlike the initial scheme, ATPS required Third-Party 1616 Services to use specific non-standard DKIM signatures to signal use 1617 of the ATPS authorization strategy. ATPS also required the DKIM 1618 signatures used by Third-Party Services to somehow determine the 1619 different label encoding employed by the many Trusted Domains without 1620 any defined discovery or exchange method. 1622 Both of these changes made deployment impractical by impacting 1623 systems not benefiting from additional alignment requirements. 1624 Third-parties have often been offering free services for decades. 1625 Even renaming From headers would impair normal handling. Those 1626 offering these services should not be expected to carry the burden of 1627 enabling a new Trusted Domain compliance scheme. Trusted Domains 1628 should offer the information needed to avoid disrupting these 1629 services instead, which is the purpose of TPA-Labels. 1631 Rather, the Trusted Domain seeking cooperative handling and receiving 1632 receiver feedback necessary to mitigate disruption should handle this 1633 burden instead. It is the Trusted Domain that directly benefits 1634 after all. There should not be unnecessary and problematic encoding 1635 schemes or assertions of delivery chains being expected of any Third- 1636 Party Service. Such matters are simply not their concern nor in 1637 their benefit. 1639 It seems the added complexities found in ATPS were to defend against 1640 a single DNS transaction. However, before this transaction occurs, 1641 the Third-Party must permit the validation of their own domain. Even 1642 then, a Third-Party checking transactions only occur after the domain 1643 is not within the Trusted Domain's alignment assertions. An 1644 assertion that can always be removed at any point. It is clearly in 1645 the interest of the Trusted Domain where the checking transaction 1646 represents a very minor contribution in support of desired receiver 1647 cooperation. 1649 Tailoring their TPA-Label list to suit their own users should 1650 discourage non-cooperative references to their domain. As more 1651 domains reference a common "_tpa." zone, the clout of that zone 1652 increases at a very moderate cost. This additional clout better 1653 ensures timely responses to abuse notifications. In this manner, 1654 DMARC/TPA-Labels would be helping to improve anti-abuse cooperation. 1655 In that light, TPA-Labels should be considered a sound investment and 1656 not an unwanted burden. 1658 ATPS required new tags be included in Third-Party DKIM signatures. 1659 These were "atps" and "atpsh" to construct a chain of "d=" and 1660 "atps=". This added complexity without any immediate benefit. 1661 Determining optional label encoding without any defined discovery 1662 method overlooks that authorization is only possible after the Third- 1663 Party Domain has been validated. A complete lack of ATPS deployment 1664 should have been expected since necessary changes did not align with 1665 benefits. 1667 In contrast, TPA-Labels do not require ANY change be made by 1668 authorized third-parties. Disrupting legitimate communications 1669 imposes inordinate support costs as a result of erroneously asserting 1670 strict alignment practices. The resulting disruption will eventually 1671 cause the domain's assertions to be ignored. If this disruption 1672 becomes endemic, assertions of other domains will become ignored as 1673 well. Domains wishing to benefit from their handling advice being 1674 employed while sending legitimate messages that may not retain their 1675 asserted alignment practices, should be offering the needed TPA-Label 1676 exception information. This information is essential and is only 1677 known by the Trusted Domain through their DMARC feedback. 1679 At this time, it is not practical for large ISPs to make strict DMARC 1680 assertions. Strict alignment assertions exclude normal Third-Party 1681 Services that modify the requisite alignment. TPA-Label lists 1682 specifically tailored to handle their users' desired Third-Party 1683 Services will permit their users to have normal email use. While 1684 entailing some administrative effort, TPA-Labels will generally be of 1685 benefit to their users by widely discouraging any spoofing of their 1686 messages. This affords greater protection for the users and the 1687 user's recipients. 1689 SPF purported to provide an anti-spoofing feature for an unseen 1690 parameter. Nevertheless, its strict IP address authorization causes 1691 problems and is largely disregarded for anything other than limiting 1692 the sending of DSNs or the scoring of messages. Many institutions 1693 will benefit by ensuring their strict DMARC assertions are not 1694 disruptive. Exercising this care will help retain recipient's trust 1695 in their assertions and the veracity of their messages. TPA-Labels 1696 would allow these institutions a means to use informal Third-Party 1697 Services with minimal administrative effort. Rather than using 1698 subdomains that lack DMARC restrictions, suitable Third-Party 1699 Services can be authorized by TPA-Labels. This approach offers a 1700 proactive method for recipients to better filter possible phishing 1701 attempts by not exposing them to unrestricted subdomain abuse. 1703 TPA-Label publishing is similar to VBR ([RFC5518]). However, it 1704 leverages Third-Party validation confirmed by labels held in the 1705 Trusted Domain. DNS also permits the information to be transparently 1706 made available from other domains whenever desired. TPA enables 1707 domains a means to protect their recipients. By implementing DMARC/ 1708 TPA-Labels, these domains should be better able to stand on their own 1709 merit. 1711 Authors' Addresses 1713 Douglas Otis 1714 Trend Micro 1715 10101 N. De Anza Blvd 1716 Cupertino, CA 95014 1717 USA 1719 Phone: +1.408.257-1500 1720 Email: doug_otis@trendmicro.com 1722 Daniel Black 1723 Canberra ACT 1724 Australia 1726 Email: daniel.subs@internode.on.net