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