idnits 2.17.1 draft-otis-tpa-label-00.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 1403 has weird spacing: '... int ret_v...' == Line 1483 has weird spacing: '... else if (c...' -- The document date (May 27, 2014) is 3621 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 567, but not defined == Missing Reference: 'ANY' is mentioned on line 694, but not defined -- Looks like a reference, but probably isn't: '20' on line 1409 -- Looks like a reference, but probably isn't: '33' on line 1409 ** 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 28, 2014 May 27, 2014 7 Third-Party Authorization Label 8 draft-otis-tpa-label-00 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 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 . . . . . . . . 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 . 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 16 87 14. TPA-Label Resource Record Version . . . . . . . . . . . . . . 16 88 15. TPA-Label Resource Record Scope Syntax . . . . . . . . . . . . 16 89 15.1. Authorized Validated Domains . . . . . . . . . . . . . . . 16 90 15.2. Header Dependent Authorizations . . . . . . . . . . . . . 17 91 15.2.1. List-ID Header Field . . . . . . . . . . . . . . . . . 17 92 15.2.2. Sender Header Field . . . . . . . . . . . . . . . . . 17 93 15.2.3. Combined 'L' or 'S' Scopes . . . . . . . . . . . . . . 17 94 15.3. DKIM signed domain . . . . . . . . . . . . . . . . . . . . 17 95 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. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 18 101 16. TPA-Label Resource Record Query Transactions . . . . . . . . . 19 102 17. TPA-Label Resource Record Compliance Extension . . . . . . . . 19 103 18. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 20 104 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 105 19.1. Moving RFC6541 to historic . . . . . . . . . . . . . . . . 21 106 19.2. TPA-Label (TPA-LLD) Parameters . . . . . . . . . . . . . . 21 107 19.3. Email Authentication Method Registry . . . . . . . . . . . 22 108 19.4. Email Authentication Result Names Registry . . . . . . . . 23 109 19.5. Third Party Authorizations Labels Registry . . . . . . . . 23 110 19.6. Third Party Authorizations Scope Registry . . . . . . . . 24 111 20. Security Considerations . . . . . . . . . . . . . . . . . . . 24 112 20.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 24 113 20.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 25 114 20.3. Benefits to Trusted Domains . . . . . . . . . . . . . . . 25 115 20.4. Risks to Trusted Domains . . . . . . . . . . . . . . . . . 26 116 20.5. Benefits to Third Party Signers . . . . . . . . . . . . . 27 117 20.6. Risks caused by Third Party Signers . . . . . . . . . . . 27 118 20.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 27 119 20.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 27 120 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 121 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 122 22.1. Normative References . . . . . . . . . . . . . . . . . . . 28 123 22.2. Informative References . . . . . . . . . . . . . . . . . . 29 124 Appendix A. DNS Example of TPA-Label Resource Record placement . 31 125 Appendix B. C code for label generation . . . . . . . . . . . . . 32 126 Appendix C. History of Prior Efforts . . . . . . . . . . . . . . 37 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 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], this 415 could allow authorizations to be exploited. 417 8.1. Third Party Authorization - Closed Mailing List Example 419 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 420 mailing list with a closed posting policy. The mailing list 421 redistributes email which breaks the Trusted Domain Alignment, and 422 the mailing list offers a means to validate the mailing list domain 423 and includes an Authentication-Results header field for posted 424 messages. The closed posting policy can be enforced by requiring 425 subscribers to validate control of their Author Addresses by 426 responding to encoded "pingback" email sent to these addresses. 428 Since the mailing list validates their domain as indicated in the 429 TPA-Label, and validates control of the posted message Author 430 Address, and includes Authentication-Results header fields, and 431 includes a List-ID header field, the referenced TPA-Label Resource 432 Record can include an 'L' scope value to stipulate that the Third- 433 Party Domain messages contain an authorized List-ID domain. 435 8.2. Third Party Authorization - Open Mailing List Example 437 The Trusted Domain wants to deploy a TPA-Label Resource Record for a 438 mailing list with an open posting policy. The mailing list 439 redistributes email in a way that breaks Trusted Domain alignment, 440 does not post from an Author Address not in compliance with DMARC, 441 offers a means to validate the mailing list domain, and it includes 442 an Authentication-Results header field for posted messages. 444 Since the mailing list validates the domain as indicated in the TPA- 445 Label, and is configured to include Authentication-Results header 446 fields, and includes a List-ID header field, the referenced TPA-Label 447 Resource Record can include an 'L' scope value to stipulate the 448 Third-Party Domain messages contain an authorized List-ID domain. 450 8.3. Third Party Authorization Example - Sender Header Field 452 Trusted Domain "example.com" wishes to temporarily employ the service 453 agency "temp.example.org" to handle overflow secretarial support. 455 The agency "temp.example.org" sends email on behalf of the executive 456 staff of "example.com" and adds the Sender header field of 457 "secretary@temp.example.org" in the email. 459 Since "temp.example.org" only allows its own staff to email through 460 its server which adds "temp.example.org" DKIM signatures, a TPA-LLD 461 can include the "temp.example.org" domain with an 'S' and 'd' scope 462 to specifically authorize DKIM signed messages containing the Sender 463 header field, to help ensure these messages are not handled as 464 phishing attempts. 466 8.4. Services Lacking DKIM Signatures 468 8.4.1. Abuse and DSN Reporting 470 There is likely little interest for an otherwise uninvolved domain to 471 receive a massive number of bogus messages being returned as 472 feedback. Often the purpose of feedback is to discover compromised 473 systems or accounts actively being exploited in some manner. Unless 474 the Trusted Domain is confirmed as having handled or authorized the 475 handling of the message, only statistics and samples should be 476 reported to the associated Autonomous System [RFC1930], and perhaps 477 to the Trusted Domain when interest is expressed. 479 The 'd', 'e', 'h', 'm', and 't' scope options within the TPA-LLD 480 records allow the Trusted Domain to be associated through various 481 methods. In this case, appropriate DSN or abuse reporting to the 482 Trusted Domain is better assured as well. 484 8.4.2. Third Party Authorization Example - SMTP Host 486 Trusted Domain "example.com" makes use of invite services. This 487 service does not utilize DKIM, where the host name given by the EHLO 488 command is "invite.example.net". The Trusted Domain can authorize 489 the domain "invite.example.net" or "example.net" with the scope of 490 'e' to improve acceptance of messages that are sent on behalf of 491 "example.com" from this outbound server. 493 8.4.3. Third Party Authorization Example - Return Path 495 Trusted Domain "example.com" makes use of tell-a-friend services. 496 This service does not utilize DKIM with its own return path as 497 "customer@taf.example.net" in the SMTP exchange. The Trusted Domain 498 can authorize the domain "taf.example.net" with the scope of 'm' to 499 improve acceptance of messages that are sent on behalf of 500 "example.com" from this outbound server. 502 8.4.4. Use of Path Authorization 504 Those using validations related to 'e', 'h', 'm' scope options should 505 not authorize domains requiring more than an average number of 506 network transactions. Those implementing DMARC should also limit the 507 number of DNS transactions attempted, otherwise this could negatively 508 impact unrelated domains when evaluating path related validation. 510 Methods that create subsequent transactions based upon the macro 511 expansion of email-address local-parts should not be used. 512 Libraries that process SPF [RFC7208] record scripts may invoke a 513 large number of DNS transactions from cached records, and target 514 unrelated domains with queries modulated by the local-part 515 component through receiver macro expansion. 517 9. DNS Representation 519 The receiver obtains domain authorizations with a DNS query for an IN 520 class TXT TPA-Label Resource Record located below the 521 "_smtp._tpa." location. The TPA-Label itself is 522 generated by processing the domain in question, which normally 523 matches the DKIM signature's "d=" parameter. The Trusted Domain 524 provides authorization for other domains with the existence of a TPA- 525 Label TXT resource record. When a "tpa" tag value exists, it MUST 526 include the referenced domain before authorization is valid. This 527 represents an informal authorization on behalf of the Trusted Domain 528 which can be limited by the "scope" tag value for specific message 529 elements. 531 A Trusted Domain may wish to delegate the listing of Third-Party 532 Services to a different administrative domain. Ideally, this would 533 be accomplished by delegating the _tpa. zone to the 534 administrative entity handling publication of TPA-Label Resource 535 Records. This delegation could also be done unilaterally with a 536 DNAME [RFC6672] resource record published at _smtp._tpa.. 539 Character-strings contained within the TXT resource record are 540 concatenated into forming a single string. A character-string, as 541 defined in [RFC1035] Section 3.3 for resource records, is a single 542 length octet followed by that number of characters treated as binary 543 information. 545 The TPA-Label Resource Records should be located at these domains: 547 ._smtp._tpa.. 549 10. TPA-Label and Tag Syntax Definitions 551 Augmented BNF for Syntax Specifications: 553 asterisk = %x2A ; "*" 554 dash = %x2D ; "-" 555 dot = %x2E ; "." 556 underscore = %x5F ; "_" 557 ANY = asterisk dot ; "*." 558 dns-char = ALPHA / DIGIT / dash 559 id-prefix = ALPHA / DIGIT 560 label = id-prefix [*61dns-char id-prefix] 561 sldn = label dot label 562 base-char = (dns-char / underscore) 563 domain = *(label dot) sldn 565 FWS = ([*WSP CRLF] 1*WSP) ; omits RFC5322 obs-FWS 566 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 567 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 568 tag-name = ALPHA 0*ALNUMPUNC / "v" / "scope" / "tpa" 569 tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] 570 ; WSP and FWS prohibited at beginning and end 571 tval = 1*VALCHAR 572 VALCHAR = %x21-3A / %x3C-7E 573 ; EXCLAMATION to TILDE except SEMICOLON 574 ALNUMPUNC = ALPHA / DIGIT / "_" 576 11. TPA-Label Generation 578 The TPA-Label is generated by nesting functions as follows: 580 "base32" function is defined in [RFC4648]. 582 "sha1" function is defined in [FIPS.180-2.2002]. 584 "lcase" converts upper-case ALPHA characters to lower-case. 586 "tpa-domain" is normally the "d=" tag value defined in Section 3.5 587 of [RFC6376]. 589 (underscore) base32( sha1( lcase(tpa-domain))) 591 The TPA-Label is created from the hash value returned by the "sha1" 592 function of the tpa-domain expressed in lower case ASCII. Any 593 terminating period is not included with the tpa-domain, as indicated 594 by the ABNF definition. 596 Note: No newline character, 0x0A, is to be appended to the end of 597 the domain name, as might occur with the command line generation 598 of sha1 values. For example, these command line appended newlines 599 can be avoided by using the 'echo -n" option. 601 The label encoding process inputs the hash as a byte stream of four 602 40-bit data blocks where each data block outputs 8 encoded 603 characters. Proceeding from left to right, a 40-bit input group is 604 formed by concatenating 5 bytes. The 40-bit input is then treated as 605 8 concatenated 5-bit groups, each of which is translated into a 606 single digit of the base32 alphabet. The bit stream is ordered with 607 the most-significant-bit first, being the high-order bit of the first 608 byte. The entire output is then concatenated first to last, left to 609 right, into 32 characters prefixed with an underscore. 611 12. TPA-Label TXT Resource Record Structure 613 Every TPA-Label TXT resource record MUST start with the version tag, 614 so the first six characters of the record are lowercase "v=tpa1", 615 TPA-Label syntax descriptions for additional tags follow the tag- 616 value syntax described in Section 3.2 of [RFC6376]. Unrecognized 617 tags and tags with illegal values MUST be ignored. In the ABNF 618 below, the WSP token is inherited from [RFC5322]. The ALPHA and 619 DIGIT tokens are imported from [RFC5234]. 621 The tags used in TPA-Label Resource Records are as follows: 623 +------------+--------------------------------------+ 624 | Tag | Function | 625 +------------+--------------------------------------+ 626 | v | Label Version (version-tag) | 627 | scope | Authorization Scope List (scope-tag) | 628 | tpa | Authorized Domains List (tpa-tag) | 629 +------------+--------------------------------------+ 631 TPA-Label Tags 633 +--------------+----------------------+--------------------------+ 634 | scope values | Field or Parameter | Method | 635 +--------------+----------------------+--------------------------+ 636 | L | List-ID Header Field | Match List-ID Identifier | 637 | S | Sender Header Field | Match Address Domain | 638 | d | DKIM Signature | Match Signature Domain | 639 | e | SMTP Hostname | Resolve Hostname IP Addr | 640 | h | SMTP Hostname | Pass SPF with Hostname | 641 | m | MailFrom | Pass SPF with MailFrom | 642 | t | SMTP Hostname | Cert of Hostname | 643 +--------------+----------------------+--------------------------+ 645 TPA-Label Scope Values 647 13. TPA-Label Resource Record Definition 649 Tags in the TPA-Label Resourse Record are shown below. The ver-tag 650 MUST be present as the left most tag. Unrecognized tags MUST be 651 ignored. 653 TPA-Label Resource Record Definition 654 tpalabelrr = v-tag [";"] 0*( 1*(WSP) tag-list) ] 656 14. TPA-Label Resource Record Version 658 Label Version (Required). This tag defined the version of the TPA- 659 Label. Only recognized scope values offer any form of DMARC 660 authorization. 662 "scope" tag 663 v-tag = %76.3d.74.70.61.31 ; "v=tpa1" 665 15. TPA-Label Resource Record Scope Syntax 667 Authorization Scope List (Optional). This tag defines a list of 668 scoping assertions for various email-address locations within the 669 message. Only recognized scope values offer any form of DMARC 670 authorization. 672 "scope" tag 673 as_val = "L" / "S" / "d" / "e" / "h" / "m" / "t" 674 as-list = %x73.63.6f.70.65 *WSP "=" [ as_val 0*( 1*(WSP) as_val )] 676 15.1. Authorized Validated Domains 677 Authorized validated domain list. (optional) This tag, when present, 678 MUST repeat all or portions of the domain encoded within the TPA- 679 Label Resource Record. This option ensures the proper handling of 680 possible hash collisions. When a domain is prefixed with the "*." 681 ANY label, then all subdomains of this domain are to be considered 682 included within the list. When the 'tpa' tag is not present or has 683 no value, it should be assumed to compare with the domain used to 684 generate the TPA-Label. The purpose of the ANY label is to reduce 685 the size of the resource records. Containing the entire string to 686 confirm hostnames or List-ID content is unnecessary. The hash label 687 must still be an exact match of the domain authorized. 689 Use of the ANY label is not intended to support wildcards for 690 referencing hash labels. No wildcard labels are to be used below the 691 "_tpa." label to access DNS resources. 693 "tpa" tag 694 ad_val = [ANY] domain 695 ad-list = %x74.70.61 *WSP "=" [ ad_val 0*( 1*(WSP) ad_val )] 697 15.2. Header Dependent Authorizations 699 15.2.1. List-ID Header Field 701 The "L" scope asserts that authorization is valid only when a List-ID 702 identifier of the List-ID header field [RFC2919] contains a domain 703 that is within a domain listed in the TPA-LLD "tpa" tag. 705 The syntax of the List-Id header field is as follows: 706 list-id-header = "List-ID:" [phrase] "<"identifier">"CRLF 708 15.2.2. Sender Header Field 710 The "S" scope asserts that authorization is valid only when the 711 domain in the Sender header field is within the TPA-LLD. 713 15.2.3. Combined 'L' or 'S' Scopes 715 When combined, the scopes 'L' and 'S' require that either a List-ID 716 identifier of the List-ID header field or the Sender header field 717 must contain a domain within the TPA-LLD for the authorization to be 718 valid. 720 15.3. DKIM signed domain 722 15.3.1. DKIM signed 723 The "d" scope asserts that messages carrying the Trusted Domain 724 within the From header field are authorized to be signed by the TPA- 725 LLD. 727 15.4. SMTP Host domains 729 The "e" scope asserts that host names given in [RFC5321] EHLO or HELO 730 commands within TPA-LLD is authorized when the hostname resolves the 731 server's IP address. 733 15.5. SMTP Host domains 735 The "h" scope asserts that host names given in [RFC5321] EHLO or HELO 736 commands within TPA-LLD is authorized only when this hostname 737 submitted to an SPF [RFC7208] process returns pass. 739 15.6. MailFrom Parameter 741 The "m" scope asserts that an email-address domain in the [RFC5321] 742 MAIL command within a TPA-LLD is authorized only when this email- 743 address submitted to an SPF [RFC7208] process returns pass. 745 15.7. SMTP Host domains 747 The "t" scope asserts that host names given in [RFC5321] EHLO command 748 after [RFC3207] negotiation where the Cert DNS-ID domain is within 749 TPA-LLD is authorized. It will also be interesting to see whether 750 [I-D.ietf-dane-smtp-with-dane] establishes a way to authenticate 751 sending domains. 753 Note to RFC Editor: Remove this comment before publishing. 754 Currently, no general practice employs certificates to confirm the 755 domain of the client initiating a connection. This may be needed 756 for clients within IPv6 IP address space where tunneling, carrier 757 grade NATs, and rapid space assignment without any practical 758 reverse mapping reduces the effectiveness of IP address based 759 reputations. 760 There is an existing TLS option for SMTP and an ongoing effort to 761 standardize automated server confirmation. It might be possible 762 to leverage this effort to establish practices used at the client. 763 See conversations defined in [RFC4954] Section 4. For information 764 related to ongoing server related efforts see: 765 [RFC6125] and [RFC6698] 767 16. TPA-Label Resource Record Query Transactions 769 The discovery of TPA-Label Resource Records need not be subsequent to 770 the discovery of the DMARC record. However, when no DMARC record is 771 discovered which includes the tag value of "tpa", the verifier MAY 772 assume no TPA-Label Resource Records have been published. Otherwise, 773 when there is no Trusted Domain validation, the discovery of TPA- 774 Label Resource Records should be attempted. 776 17. TPA-Label Resource Record Compliance Extension 778 The signing practice compliance assessment of Third Party Signatures 779 is a discretionary operation performed by the verifier. For messages 780 that do not have valid Trusted Domain alignment, a verifier may 781 decide to assess compliance for Third Party messages when there is a 782 DMARC tag of "tpa". Elements then referenced in the TPA-Label scope 783 values of "d", "m", "e", "h", "t" are to be checked in their listed 784 succession. One of the following sets of conditions MUST be met for 785 the result to be considered a pass: 787 For Third Party DKIM signatures, the following represents the set of 788 conditions to be checked: 790 o The Third Party Signature MUST validate according to [RFC6376]. 791 o A TXT resource record, referenced by a TPA-Label created by the 792 DKIM signature "d=" tag, MUST exist in DNS. 793 o The discovered TPA-Label Resource Record structure MUST be valid. 794 o The domain that created the TPA-Label MUST be within the TPA-LLD. 795 o Where a scope of 'd' is specified, the Trusted Domain MUST have an 796 authorized DKIM signature. 797 o Where a scope of 'L' or 'S' is specified, a List-ID identifier in 798 the List-ID header field or a Sender header field MUST contain a 799 domain within the TPA-LLD. This provides Third-Party services a 800 reason to ensure their outbound messages do not spoof these 801 associated header fields. 803 For non-DKIM validations, the TXT record discovery process continues 804 until a TPA-Label Resource Record structure is found where: 806 One of the three possible TXT resource records is checked in their 807 listed succession. Each would be referenced by an 'h' or 'e' or 't' 808 related domain given by [RFC5321] EHLO or HELO command, this domain 809 with left-most label omitted, or by an 'm' related email-address 810 domain within the [RFC5321] MAIL command. 812 o The discovered TPA-Label Resource Record Structure is valid. 814 o The domain that created the TPA-Label is within the TPA-LLD. 815 o The domain that created the TPA-Label corresponds with a listed 816 scope of 'e', 'h' or 'm' or 't'. 817 o Where a scope of 'L' or 'S' is specified, either the domain in 818 List-ID given by [RFC2919] in the List-ID header field is within 819 the TPA-LLD, or a Sender header field contains a domain within the 820 TPA-LLD respectively. 821 o Once these four conditions have been met, for 'h' or 'm' scopes 822 the domain MUST be confirmed by submitting the domain to an SPF 823 process that then returns pass. The 'e' scope MUST be confirmed 824 by a forward DNS reference that resolves the address of the SMTP 825 client. The 't' scope MUST be confirmed by the DNS-ID in the 826 client certificate. 828 When the TPA-Label Resource Record can not be retrieved due to some 829 error that is likely transient in nature, such as "SERVFAIL" for 830 example, the result of the TPA-Label Resource Record compliance 831 assessment is "temperror". 833 When the TPA-Label Resource Record retrieval returns a DNS "NOERROR", 834 but not with a single record, the result of the TPA-Label Resource 835 Record compliance assessment is "permerror". 837 When the TPA-Label Resource Record can not be retrieved with a DNS 838 "NXDOMAIN" response, the result of the TPA-Label Resource Record 839 compliance assessment is "nxdomain". 841 18. Privacy Considerations 843 As with other authorization schemes that utilize DNS, relationships 844 are publicly revealed. This is the nature of SPF authorization which 845 reveals first party services being used. A TPA-Label on the other 846 hand can resolve a hash obscured Third-Party Service. Unlike SPF, a 847 TPA-Label does not include any user identity related parameters and 848 does not reveal any users specific relationships. In addition, these 849 relationships are accessed with a hash of the entire domain. Use of 850 a few random subdomains can inhibit discovery of these relationships. 851 However, the low latency of DNS means resource records can not be 852 assumed to remain secret. 854 Even so, disclosures of Third-Party Services might be justified by 855 dissuading malefactors who have compromised the Trusted Domain and 856 then are able to subsequently spoof the discovered personal 857 relationships. Such spoofing might be seen as causing getter harm 858 then public knowledge of possible Third-Party Services used by the 859 Trusted Domain's users. 861 Overhead associated with managing a "_tpa." zone is fairly small and 862 is offset by the squelching of DMARC feedback generation and the 863 remediation of a loss of legitimate messages. Alternatives to TPA- 864 Labels are likely to be the dissemination of plaintext lists of 865 domains known to cause alignment failures, although operating in full 866 compliance with SMTP protocols and practices. 868 19. IANA Considerations 870 19.1. Moving RFC6541 to historic 872 This document is seeking to replace ([RFC6541]) and to move it to 873 historic. 875 19.2. TPA-Label (TPA-LLD) Parameters 877 To accommodate the extensions to [RFC7001] needs the following 878 elements to be added: 880 +------+-----------------+ 881 | Type | Reference | 882 +------+-----------------+ 883 | tpa | (this document) | 884 +------+-----------------+ 886 TPA-Label Resource Record validation Method 888 19.3. Email Authentication Method Registry 890 To accommodate the method derived from TPA-Label Resource Record 891 processing, the IANA Registry "Email Authentication Method" defined 892 by Section 6.2 of [RFC7001] needs the following elements to be added: 894 +---------+-----------+--------+----------+-------------------------+ 895 | Method | Defined | ptype | property | value | 896 +---------+-----------+--------+----------+-------------------------+ 897 | tpa-lld | (this | domain | 3p-dom | Domain evaluated. The | 898 | | document) | | | method results from | 899 | | | | | [RFC7001] should also | 900 | | | | | be included in a | 901 | | | | | Authenticated Results | 902 | | | | | header field | 903 | | | | scope | value of scope | 904 | | | | | (Section 19.6) tag. | 905 | | | | | (When 'scope' contains | 906 | | | | | 'e', 'h' or 'm', the | 907 | | | | | iprev [RFC7001] | 908 | | | | | (Section 3) method | 909 | | | | | results should also be | 910 | | | | | included in the | 911 | | | | | Authenticated-Results | 912 | | | | | header field to capture | 913 | | | | | the SMTP client IP | 914 | | | | | address. | 915 | | | | ca-scope | The scopes | 916 | | | | | (Section 19.6) with a | 917 | | | | | compliance assessment | 918 | | | | | as pass | 919 | | | | tpa | Value of tpa | 920 | | | | | (Section 15.1) tag at | 921 | | | | | time of compliance | 922 | | | | | assessment | 923 +---------+-----------+--------+----------+-------------------------+ 925 TPA-Label Resource Record validation Method 927 19.4. Email Authentication Result Names Registry 929 To accommodate the results derived from TPA-Label Resource Record 930 processing, the IANA Registry "Email Authentication Method" defined 931 by Section 6.3 of [RFC7001] needs the following elements added: 933 +----------+----------+---------------------------------------------+ 934 | code | method | meaning | 935 +----------+----------+---------------------------------------------+ 936 | none | tpa-lld | No TPA-Label was published | 937 | pass | tpa-lld | Section 17 | 938 | tempfail | tpa-lld | Section 17 | 939 | permfail | tpa-lld | Section 17 | 940 | hdrfail | tpa-lld | The TPA-Label Resource Record scope values | 941 | | | of "S" or "L" failed to match. | 942 | nxdomain | tpa-lld | When obtaining the TPA-Label Resource | 943 | | | Record, DNS indicated this domain does not | 944 | | | exist. | 945 +----------+----------+---------------------------------------------+ 947 TPA-Label Resource Record complaince assessment Results 949 19.5. Third Party Authorizations Labels Registry 951 Names of tags that are valid in TPA-Label Resource Records with the 952 exception of experimental tags Section 12 MUST be registered in this 953 created IANA registry. 955 New entries are assigned only for values that have been documented in 956 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 957 [RFC5226]. 959 Each tag registered must correspond to a definition. 961 The initial set of values for this registry is: 963 +----------+--------------+-----------------------------------------+ 964 | tag | defined | definition | 965 +----------+--------------+-----------------------------------------+ 966 | v | Section 12 | Label Version | 967 | scope | Section 15 | Section 19.6 | 968 | tpa | Section 15.1 | List of Authorized Domains or | 969 | | | Identifiers | 970 +----------+--------------+-----------------------------------------+ 972 TPA-Label Resource Record compliance assessment Results 974 19.6. Third Party Authorizations Scope Registry 975 Values that correspond to Section 15 MUST be registered in this 976 created registry: 978 New entries are assigned only for values that have been documented in 979 a published RFC that has had IETF Review, per IANA CONSIDERATIONS 980 [RFC5226]. 982 Each value registered must correspond to a definition. 984 The initial set of values for this registry is: 986 +------------+----------------+ 987 | value | defined | 988 +------------+----------------+ 989 | L | Section 15.2.1 | 990 | S | Section 15.2.2 | 991 | d | Section 15.3 | 992 | h | Section 15.5 | 993 | e | Section 15.4 | 994 | m | Section 15.6 | 995 | t | Section 15.7 | 996 +------------+----------------+ 998 TPA-Label Resource Record compliance assessment Results 1000 20. Security Considerations 1002 This draft extends Domain Alignment validation practices that depend 1003 on DKIM ([RFC6376]) or SPF ([RFC7208]). Most related security 1004 matters are discussed in those specifications. Additional 1005 considerations are also included in [RFC6377]. Security 1006 considerations for the TPA-LLD scheme are mostly related to attempts 1007 on the part of malefactors to falsely represent themselves as others, 1008 often in an attempt to defraud either the recipient or the alleged 1009 originator. Some receivers mistakenly bypass validation of the 1010 [RFC5322] header fields because a signature from a Trusted Domain had 1011 been confirmed as perhaps suggested in [RFC5863]. Do not omit the 1012 validation of header fields unless the message is not accepted for 1013 other reasons. 1015 Additional security considerations regarding DKIM signing practices 1016 may be found in the DKIM threat analysis [RFC4686]. 1018 20.1. Benefits to Recipients 1020 The verifier, after validating a Federated Domain, will have 1021 significantly greater confidence in the Third-Party, than when no 1022 TPA-Label Resource Record is obtained. This enhanced confidence may, 1023 at the recipients' discretion, cause a message to be delivered to the 1024 recipient with less stringent assessments. 1026 20.2. Risks to Recipients 1028 The decisions a recipient makes in regard to message filtering based 1029 on TPA-Label Resource Records are likely to depend on the system 1030 integrity of the Third Party with respect to the validation methods 1031 determined by authorization scope labels. When the 'e', 'h', or 'm' 1032 scoped domain is not confirmed, or the Third-Party Domain does not 1033 validate the submitter, there is a risk of accepting potentially 1034 spoofed messages. Authentication-Results header fields then play an 1035 important role when there is no out-of-band authentications 1036 confirming the submitter. Without proper Authentication-Results 1037 handling by the Third-Party, there is also risk of accepting 1038 potentially spoofed messages. 1040 With the TPA-Label specification, third party validation provides 1041 verifiable value. Implementers should consider the possibility a 1042 malefactor will send a message having a large number of valid DKIM 1043 Signatures. Verifying all the signatures may consume a large amount 1044 of processing resources. As such, it might be worth checking for the 1045 existence of a TPA-Label Resource Record first to minimize network 1046 amplification concerns. Section 16 describes a quick check to see if 1047 TPA-Label Resource Records may exist. Additionally, validating DKIM 1048 signatures and obtaining related resource records might be limited to 1049 known trustworthy domains. 1051 Services that depend only upon path authorizations might permit the 1052 Trusted Domain to be spoofed and yet obtain acceptance. During such 1053 events, the Trusted Domain might need to retract its authorization 1054 from the service. For this reason, path related validation based on 1055 IP addresses should only be used as a carefully monitored interim 1056 solution. 1058 20.3. Benefits to Trusted Domains 1060 TPA-Label Resource Records can replace domain delegations, selector/ 1061 key record mirroring, or key exchanges. A significant number of 1062 details are associated with selector/key records. These details 1063 include user limitations, suitable services, key resource record's 1064 Time-To-Live, revocation and update procedures, and how the DKIM 1065 Signature header field's 'i=' semantics are to be applied. In 1066 addition, services that depend upon DKIM keys are better secured by 1067 not delegating these DKIM keys, where instead the TPA-LLD scheme 1068 allows Trusted Domains an ability to limit the scope of their 1069 authorizations, while also not being mistaken for having 1070 authenticated the entity submitting the message. 1072 TPA-Label Resource Records convey which domains are authoritative 1073 even when they are not the Trusted Domain. However, Authorized 1074 Domains are unable to utilize the DKIM signature's 'i=' semantics to 1075 directly assert which identifiers on whose behalf a signature was 1076 added. As such, no domain should be authorized unless it is trusted 1077 to ensure the Federated Identity of an email undergoes validation 1078 that offers acceptable protections for the Trusted Domain. For 1079 example, such validation might ensure submitting entities have 1080 demonstrated receipt of "pingback" messages sent to the Federated 1081 Identity (Author's address) contained within the messages being 1082 signed. 1084 By deploying TPA-Label Resource Records, Trusted Domains benefit when 1085 recipients assess signing practice compliance by using the TPA-LLD 1086 scheme. These recipients will be less likely to drop the Trusted 1087 Domain's genuine messages, whenever the Trusted Domain attempts to 1088 restrict acceptance. Restricting acceptance of non-compliant 1089 messages is the basic motivation for publishing DMARC records. In 1090 addition, recipients are more likely to validate signatures by an 1091 Authorized Domain. 1093 Broader use of strict DMARC alignment assertions provides a greater 1094 likelihood of being able to eliminate a broader range of non- 1095 compliant messages, in addition to improving acceptance from 1096 authorized sources. TPA-Labels also allow Trusted Domains to control 1097 message Sender and List-ID attributes, to exclude problematic 1098 validation methods or include others as they become available. 1100 Trusted Domains having good reputations might extend limited 1101 compliance assessment resources to otherwise unknown domains or SMTP 1102 Clients that are referenced by their TPA-LLD. 1104 20.4. Risks to Trusted Domains 1106 As indicated in Section 8, it is ultimately an issue of trusting the 1107 Third Party Domain to do the right thing and not generate, or allow 1108 others to generate, messages that falsely appear to be from the 1109 Trusted Domain. The authentication methods in place for different 1110 email elements need to be carefully reflected in the scope of the 1111 TPA-LLD. 1113 Authorization of mailing lists with TPA-LLD could cause a loss of 1114 confidentiality in mailing list participation by the Trusted Domain. 1115 This might help malefactors deduce which subscription related email 1116 the Trusted Domain may receive. Because of the hashing function in 1117 generating the TPA-Label, anyone wishing to discover which domains 1118 are being authorized, has to probe each TPA-Label based on the exact 1119 domain. In addition, service organizations or community groups are 1120 able to share comprehensive lists. Such possible sharing means even 1121 though a domain has been authorized, that in itself does not mean the 1122 Trusted Domain is exchanging messages with the Authorized Domain. 1124 20.5. Benefits to Third Party Signers 1126 Third Party Signers benefit by allowing those using their service, 1127 the autonomy to authorize their service without needing to exchange 1128 DKIM key related details. This is particularly useful for mailing 1129 lists. 1131 20.6. Risks caused by Third Party Signers 1133 As mentioned before, Authorized Third Party Signers need to validate 1134 messages from Trusted Domains. This validation provides a safety 1135 mechanism for the Trusted Domain and their recipients. The Third 1136 Party may not be aware of the validation value or the message 1137 elements involved, and as a result make changes without understanding 1138 the impact this may have on Trusted Domains and their recipients. 1139 For example, the Third Party might stop DKIM signing or stop applying 1140 Authentication-Results header fields. The unexpected exposure that 1141 this might enable could allow abuse and prove detrimental for both 1142 the Trusted Domain and their recipients. 1144 20.7. SHA-1 Collisions 1146 The use of the SHA-1 hash algorithm does not represent a security 1147 concern. The hash simply ensures a deterministic domain-name size is 1148 achieved. Unexpected collisions can be detected and handled by using 1149 the extended TPA-Label Resource Record "tpa=" option. The use of 1150 TPA-Label Resource Records without the TPA-Label "tpa=" options does 1151 present an opportunity for an adversary to attempt to find a hash 1152 collision. Message spoofing outside the realm of DKIM protection is 1153 likely easier to achieve than finding hash collisions. There is 1154 minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains has 1155 less than a 0.1 percent risk of any two domain labels colliding. 1157 20.8. DNS Limits 1159 Use of the TPA-Label Resource Records, rather than simply listing the 1160 Authorized Domain, ensures the DNS record size is independent of the 1161 Third Party Domain. The typical domain name size has been steadily 1162 increasing. This increase has been caused by domain names that 1163 encode international character sets. Perhaps, soon there will be a 1164 further increase spurred by an expanse of TLDs having larger 1165 international labels. 1167 The maximum domain name size allowed, per [RFC1034] Section 3, is 255 1168 bytes (or octets). Each label has a byte for its length. Every 1169 domain name adds an additional byte by having a right-most label that 1170 represents the root "." signified as a zero length label. A labeling 1171 scheme that combines together a listed domain with the publishing 1172 domain separated by some label for this convention, reduces the 1173 maximal domain name in half, where the convention label reduces this 1174 further. 1176 If "_smtp._tpa." were used as the convention label with a simple 1177 listing method, the maximum domain name size this supports would be 1178 128 bytes. The suffix for TPA-Labels is "_smtp._tpa." which consumes 1179 11 bytes. The TPA-Label itself consumes 34 bytes. A domain that 1180 publishes the TPA-Labels in its domain would then have 122 bytes 1181 available for their Trusted Domain. This permits the authorization 1182 of any domain having a valid length with a deterministic amount of 1183 space available for resource records. 1185 Normally, DNS messages should not exceed 512 bytes as per Section 1186 2.3.4 of [RFC1035]. Using TPA-Label Resource Records in the DNS, as 1187 described by this document, consumes a consistent 50 bytes, in 1188 addition to the domain name publishing the TPA-Labels. With this 1189 being constant, a limit can be determined as a constraint to resource 1190 record size, to ensure a response does not exceed the maximum DNS 1191 message size. DNS servers that add additional resource records, for 1192 nameservers as an example, will further reduce available resource 1193 record capacity. Domains publishing TPA-Labels exceeding the DNS 1194 message limit will need to rely on recipients using TCP for DNS 1195 retrieval, or EDNS0 [RFC6891] for extended DNS lengths. 1197 21. Acknowledgements 1199 Jeff MacDonald, Michael Deutschmann, Frank Ellermann, Murray 1200 Kucherawy, Wietse Venema, Alessandro Vesely, and John Leslie. 1202 22. References 1204 22.1. Normative References 1206 [FIPS.180-2.2002] 1207 National Institute of Standards and Technology, "Secure 1208 Hash Standard", FIPS PUB 180-2, August 2002, . 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, March 1997. 1214 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1215 and Namespace for the Identification of Mailing Lists", 1216 RFC 2919, March 2001. 1218 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1219 Transport Layer Security", RFC 3207, February 2002. 1221 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1222 Encodings", RFC 4648, October 2006. 1224 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1225 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1227 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1228 October 2008. 1230 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1231 October 2008. 1233 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1234 July 2009. 1236 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1237 Verification of Domain-Based Application Service Identity 1238 within Internet Public Key Infrastructure Using X.509 1239 (PKIX) Certificates in the Context of Transport Layer 1240 Security (TLS)", RFC 6125, March 2011. 1242 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1243 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1244 September 2011. 1246 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1247 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 1249 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 1250 Message Authentication Status", RFC 7001, September 2013. 1252 22.2. Informative References 1254 [I-D.ietf-dane-smtp-with-dane] 1255 Dukhovni, V. and W. Hardaker, "SMTP security via 1256 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 1257 (work in progress), May 2014. 1259 [I-D.kucherawy-dmarc-base] 1260 Kucherawy, M. and E. Zwicky, "Domain-based Message 1261 Authentication, Reporting and Conformance (DMARC)", 1262 draft-kucherawy-dmarc-base-04 (work in progress), 1263 April 2014. 1265 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1266 STD 13, RFC 1034, November 1987. 1268 [RFC1035] Mockapetris, P., "Domain names - implementation and 1269 specification", STD 13, RFC 1035, November 1987. 1271 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1272 selection, and registration of an Autonomous System (AS)", 1273 BCP 6, RFC 1930, March 1996. 1275 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1276 Identified Mail (DKIM)", RFC 4686, September 2006. 1278 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1279 for Authentication", RFC 4954, July 2007. 1281 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1282 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1283 May 2008. 1285 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 1286 Reference", RFC 5518, April 2009. 1288 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1289 "DomainKeys Identified Mail (DKIM) Development, 1290 Deployment, and Operations", RFC 5863, May 2010. 1292 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1293 Mailing Lists", BCP 167, RFC 6377, September 2011. 1295 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 1296 Authorized Third-Party Signatures", RFC 6541, 1297 February 2012. 1299 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1300 DNS", RFC 6672, June 2012. 1302 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1303 of Named Entities (DANE) Transport Layer Security (TLS) 1304 Protocol: TLSA", RFC 6698, August 2012. 1306 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1307 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1308 April 2014. 1310 Appendix A. DNS Example of TPA-Label Resource Record placement 1312 #### 1313 # Practices for Example.com email domain using example.com, isp.com, 1314 # and example.com.isp.com as signing domains. 1315 #### 1317 #### 5322.From authorization for 3P domains #### 1319 ## "isp.com" TPA-Label Resource Record ## 1320 _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com. IN TXT 1321 "v=tpa1 tpa=isp.com; scope=d;" 1323 #### 5322.Sender/List-ID authorization for 3P domains #### 1325 ## "example.com.isp.com" TPA-Label Resource Record ## 1326 _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._smtp._tpa.example.com. IN TXT 1327 "v=tpa1 tpa=*.isp.com; scope=d L S;" 1329 Appendix B. C code for label generation 1331 The following utility can be compiled as TPA-Label.c using the 1332 following: 1334 gcc -lcrypto TPA-Label.c -o TPA-Label 1336 1337 /* 1338 * TPA-Label generation utility 1339 * Copyright (c) 2010 IETF Trust and the persons identified as the 1340 * document authors. All rights reserved. 1341 * 1342 * This document is subject to BCP 78 and the IETF Trust's Legal 1343 * Provisions Relating to IETF Documents 1344 * (http://trustee.ietf.org/license-info) in effect on the date of 1345 * publication of this document. Please review these documents 1346 * carefully, as they describe your rights and restrictions with respect 1347 * to this document. Code Components extracted from this document must 1348 * include Simplified BSD License text as described in Section 4.e of 1349 * the Trust Legal Provisions and are provided without warranty as 1350 * described in the Simplified BSD License. 1351 * 1352 * This document and the information contained herein are provided on an 1353 * "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1354 * OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1355 * THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1356 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1357 * THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1358 * WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1359 */ 1360 #include 1361 #include 1362 #include 1363 #include 1364 #include 1365 #include 1366 #include 1367 #include 1368 #include 1369 #include 1370 #include 1372 #define TPA_LABEL_VERSION 102 1373 #define MAX_DOMAIN_NAME 256 1374 #define MAX_FILE_NAME 1024 1376 static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; 1377 static char sign_on[] = 1378 {"%s v%d.%02d Copyright (C) (2014) The IETF Trust\n"}; 1379 char err_cmd[] =\ 1380 "ERR: Command error with [%s]\n"; 1381 char use_txt[]=\ 1382 "Usage: TPA-Label [-i domain_input_file] [-o label_output_file][-v]\n"; 1383 char help_txt[]=\ 1384 "The options are as follows:\n"\ 1385 "-i domain name input. Defaults to stdin. Removes trailing '.'\n"\ 1386 "-o TPA-Label output. Defaults to stdout.\n"\ 1387 "-v Specifies Verbose Mode.\n\n"; 1389 static void usage(void); 1390 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1392 static void 1393 usage(void) 1394 { 1395 (void) fprintf(stderr, "\n%s%s", use_txt, help_txt); 1396 exit(1); 1397 } 1398 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1400 int 1401 main (int argc, char * argv[]) 1402 { 1403 int ret_val, in_mode, out_mode, verbose, done, i, j, k; 1404 char ch; 1405 unsigned int len; 1406 unsigned long b_5; 1407 char in_fn[MAX_FILE_NAME], out_fn[MAX_FILE_NAME]; 1408 unsigned char in_buf[MAX_DOMAIN_NAME + 2]; 1409 unsigned char sha_res[20], tpa_label[33]; 1410 FILE *in_file, *out_file; 1412 ret_val = in_mode = out_mode = verbose = done = 0; 1413 len = 0; 1415 while ((ch = getopt(argc, argv, "i:o:v")) != -1) 1416 { 1417 switch (ch) 1418 { 1419 case 'i': 1420 in_mode = 1; /* input from file */ 1421 (void) strncpy(in_fn, optarg, sizeof(in_fn)); 1422 in_fn[sizeof(in_fn) - 1] = '\0'; 1423 break; 1424 case 'o': 1426 out_mode = 1; /* out to file */ 1427 (void) strncpy(out_fn, optarg, sizeof(out_fn)); 1428 out_fn[sizeof(out_fn) - 1] = '\0'; 1429 break; 1430 case 'v': 1431 verbose = 1; 1432 break; 1433 case '?': 1434 default: 1435 (void) usage(); 1436 break; 1437 } 1438 }; 1440 if (in_mode) 1441 { 1442 if ((in_file = fopen(in_fn, "r")) == NULL) 1443 { 1444 (void) fprintf(stderr, 1445 "ERR: Error opening [%s] input file.\n", 1446 in_fn); 1447 exit(2); 1448 } 1449 } 1450 else 1451 { 1452 in_file = stdin; 1453 } 1455 if (out_mode) 1456 { 1457 if ((out_file = fopen(out_fn, "w")) == NULL) 1458 { 1459 (void) fprintf(stderr, 1460 "ERR: Error opening [%s] output file.\n", 1461 out_fn); 1462 exit(3); 1463 } 1464 } 1465 else 1466 { 1467 out_file = stdout; 1468 } 1470 if (out_mode && verbose) 1471 { 1472 (void) printf(sign_on, "TPA-Label utility", 1473 TPA_LABEL_VERSION / 100, 1474 TPA_LABEL_VERSION % 100); 1475 } 1477 for (i = 0; i < MAX_DOMAIN_NAME && !done; i++) 1478 { 1479 if ((ch = fgetc(in_file)) == EOF) 1480 { 1481 ch = 0; 1482 } 1483 else if (ch == '\n' || ch == '\r') 1484 { 1485 ch = 0; 1486 } 1488 in_buf[i] = tolower(ch); 1490 if (ch == 0) 1491 { 1492 len = i; /* string length */ 1493 done = 1; 1494 } 1495 } 1497 if (!done) 1498 { 1499 (void) fprintf(stderr, "ERR: Domain name too long.\n"); 1500 exit (4); 1501 } 1503 if (len && in_buf[len - 1] == '.') /* remove any trailing "." */ 1504 { 1505 len--; 1506 in_buf[len] = 0; /* replace trailing "." with 0 */ 1507 } 1509 in_buf[len] = 0; /* terminate string */ 1511 if (len < 2) 1512 { 1513 (void) 1514 fprintf(stderr, 1515 "ERR: Domain name [%s] too short with %d length.\n", 1516 in_buf, 1517 len); 1518 exit (5); 1519 } 1521 SHA1(in_buf, len, sha_res); 1522 if (verbose) 1523 { 1524 printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len); 1526 for (i = 0; i < 20; i++) 1527 { 1528 printf("%02x", sha_res[i]); 1529 } 1530 printf("\nTPA-Label 5 bit intervals left to right.\n"); 1531 } 1533 /* process sha1 results 4 times by 40 bits (160 bits) */ 1534 for (i = 0, j = 0; i < 4 ; i++) 1535 { 1536 b_5 = (unsigned long long) sha_res[(i * 5)] << 32; 1537 b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24; 1538 b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16; 1539 b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8; 1540 b_5 |= (unsigned long long) sha_res[(i * 5) + 4]; 1542 if (verbose) 1543 { 1544 printf(" {%010llX}->", b_5); 1545 } 1547 for (k = 35; k >= 0; k-= 5, j++) /* convert 40 bits (5x8) */ 1548 { 1549 tpa_label[j] = base32[(b_5 >> k) & 0x1F]; 1551 if (verbose) 1552 { 1553 printf(" %02X:%c", 1554 (unsigned int)(b_5 >> k) & 0x1F, 1555 tpa_label[j]); 1556 } 1557 } 1558 if (verbose) 1559 { 1560 printf ("\n"); 1561 } 1562 } 1563 if (verbose) 1564 { 1565 printf("\n"); 1566 } 1567 tpa_label[j] = 0; /* terminate label string */ 1568 fprintf(out_file, "_%s", tpa_label); 1569 printf("\n"); 1570 /* close */ 1571 if (out_mode) 1572 { 1573 if (fclose (out_file) != 0) 1574 { 1575 (void) fprintf(stderr, 1576 "ERR: Unable to close %s output file.\n", 1577 out_fn); 1578 ret_val = 6; 1579 } 1580 } 1581 if (in_mode) 1582 { 1583 if (fclose (in_file) != 0) 1584 { 1585 (void) fprintf(stderr, 1586 "ERR: Unable to close %s input file.\n", 1587 in_fn); 1588 ret_val = 7; 1589 } 1590 } 1591 return (ret_val); 1592 } 1593 1595 Appendix C. History of Prior Efforts 1597 To withstand asserting strict alignment practices, a scheme was 1598 devised that transferred the burden of a resulting disruption from 1599 receivers back to the Trusted Domains making the stringent requests. 1600 As such, a method to authorize other authenticated domains to 1601 establish informally Federated Third-Party Services, such as mailing- 1602 lists was developed. This initial scheme was then modified and 1603 proposed by ATPS [RFC6541]. Unlike the initial scheme, ATPS required 1604 Third-Party Services to use specific non-standard DKIM signatures to 1605 signal use of the ATPS authorization strategy. ATPS also required 1606 the DKIM signatures used by Third-Party Services to somehow determine 1607 the different label encoding employed by the many Trusted Domains 1608 without any defined discovery or exchange method. 1610 Both of these changes made deployment impractical by impacting 1611 systems not benefiting from additional alignment requirements. 1612 Third-parties have often been offering free services for decades. 1613 Even renaming From headers would impair normal handling. Those 1614 offering these services should not be expected to carry the burden of 1615 enabling a new Trusted Domain compliance scheme. Trusted Domains 1616 should offer the information needed to avoid disrupting these 1617 services instead, which is the purpose of TPA-Labels. 1619 Rather, the Trusted Domain seeking cooperative handling and receiving 1620 receiver feedback necessary to mitigate disruption should handle this 1621 burden instead. It is the Trusted Domain that directly benefits 1622 after all. There should not be unnecessary and problematic encoding 1623 schemes or assertions of delivery chains being expected of any Third- 1624 Party Service. Such matters are simply not their concern nor in 1625 their benefit. 1627 It seems the added complexities found in ATPS were to defend against 1628 a single DNS transaction. However, before this transaction occurs, 1629 the Third-Party must permit the validation of their own domain. Even 1630 then, a Third-Party checking transactions only occur after the domain 1631 is not within the Trusted Domain's alignment assertions. An 1632 assertion that can always be removed at any point. It is clearly in 1633 the interest of the Trusted Domain where the checking transaction 1634 represents a very minor contribution in support of desired receiver 1635 cooperation. 1637 Tailoring their TPA-Label list to suit their own users should 1638 discourage non-cooperative references to their domain. As more 1639 domains reference a common "_tpa." zone, the clout of that zone 1640 increases at a very moderate cost. This additional clout better 1641 ensures timely responses to abuse notifications. In this manner, 1642 DMARC/TPA-Labels would be helping to improve anti-abuse cooperation. 1643 In that light, TPA-Labels should be considered a sound investment and 1644 not an unwanted burden. 1646 ATPS required new tags be included in Third-Party DKIM signatures. 1647 These were "atps" and "atpsh" to construct a chain of "d=" and 1648 "atps=". This added complexity without any immediate benefit. 1649 Determining optional label encoding without any defined discovery 1650 method overlooks that authorization is only possible after the Third- 1651 Party Domain has been validated. A complete lack of ATPS deployment 1652 should have been expected since necessary changes did not align with 1653 benefits. 1655 In contrast, TPA-Labels do not require ANY change be made by 1656 authorized third-parties. Disrupting legitimate communications 1657 imposes inordinate support costs as a result of erroneously asserting 1658 strict alignment practices. The resulting disruption will eventually 1659 cause the domain's assertions to be ignored. If this disruption 1660 becomes endemic, assertions of other domains will become ignored as 1661 well. Domains wishing to benefit from their handling advice being 1662 employed while sending legitimate messages that may not retain their 1663 asserted alignment practices, should be offering the needed TPA-Label 1664 exception information. This information is essential and is only 1665 known by the Trusted Domain through their DMARC feedback. 1667 At this time, it is not practical for large ISPs to make strict DMARC 1668 assertions. Strict alignment assertions exclude normal Third-Party 1669 Services that modify the requisite alignment. TPA-Label lists 1670 specifically tailored to handle their users' desired Third-Party 1671 Services will permit their users to have normal email use. While 1672 entailing some administrative effort, TPA-Labels will generally be of 1673 benefit to their users by widely discouraging any spoofing of their 1674 messages. This affords greater protection for the users and the 1675 user's recipients. 1677 SPF purported to provide an anti-spoofing feature for an unseen 1678 parameter. Nevertheless, its strict IP address authorization causes 1679 problems and is largely disregarded for anything other than limiting 1680 the sending of DSNs or the scoring of messages. Many institutions 1681 will benefit by ensuring their strict DMARC assertions are not 1682 disruptive. Exercising this care will help retain recipient's trust 1683 in their assertions and the veracity of their messages. TPA-Labels 1684 would allow these institutions a means to use informal Third-Party 1685 Services with minimal administrative effort. Rather than using 1686 subdomains that lack DMARC restrictions, suitable Third-Party 1687 Services can be authorized by TPA-Labels. This approach offers a 1688 proactive method for recipients to better filter possible phishing 1689 attempts by not exposing them to unrestricted subdomain abuse. 1691 TPA-Label publishing is similar to VBR ([RFC5518]). However, it 1692 leverages Third-Party authentications confirmed by labels held in the 1693 Trusted Domain. DNS also permits the information to be transparently 1694 made available from other domains whenever desired. TPA enables 1695 domains a means to protect their recipients. By implementing DMARC/ 1696 TPA-Labels, these domains should be better able to stand on their own 1697 merit. 1699 Authors' Addresses 1701 Douglas Otis 1702 Trend Micro 1703 10101 N. De Anza Blvd 1704 Cupertino, CA 95014 1705 USA 1707 Phone: +1.408.257-1500 1708 Email: doug_otis@trendmicro.com 1710 Daniel Black 1711 Canberra ACT 1712 Australia 1714 Email: daniel.subs@internode.on.net