idnits 2.17.00 (12 Aug 2021) /tmp/idnits23775/draft-bkl-bimi-overview-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Blank 3 Internet-Draft Valimail 4 Intended status: Informational N. Kumaran 5 Expires: September 12, 2019 Google 6 J. Levine, Ed. 7 Standcore LLC 8 March 11, 2019 10 An Overview of the Design of BIMI 11 draft-bkl-bimi-overview-00 13 Abstract 15 Brand Indicators for Message Identification (BIMI) provides a 16 mechanism for mail senders to publish a validated logotype that mail 17 receivers can display with the senders' messages. This document 18 provides a brief overview of BIMI and examines some of the trade offs 19 and decisions in its design. 21 Discussion venue 23 Comments on this draft may be directed to the BIMI list at 24 bimi@ietf.org. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. High level architecture and data flow . . . . . . . . . . . . 3 62 3. Risks and problems of BIMI . . . . . . . . . . . . . . . . . 4 63 3.1. Private club . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Inconsistent validation . . . . . . . . . . . . . . . . . 5 65 3.3. Pay to Play . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. User Security . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Indicator Publishing Options . . . . . . . . . . . . . . . . 7 68 4.1. Message header . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. S/MIME signatures . . . . . . . . . . . . . . . . . . . . 7 70 4.3. DNS assertion records . . . . . . . . . . . . . . . . . . 8 71 5. Validation Requirements . . . . . . . . . . . . . . . . . . . 8 72 5.1. Indicator Usage and Rights Validation Scenarios . . . . . 9 73 5.2. Registered Mark . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Registered Mark (untrusted jurisdiction) . . . . . . . . 9 75 5.4. Common Use Mark . . . . . . . . . . . . . . . . . . . . . 10 76 5.5. Common Use Mark (untrusted jurisdiction) . . . . . . . . 10 77 5.6. New/Rebranded Mark . . . . . . . . . . . . . . . . . . . 10 78 5.7. Mildly Altered Mark . . . . . . . . . . . . . . . . . . . 10 79 5.8. Multiple Marks . . . . . . . . . . . . . . . . . . . . . 11 80 5.9. Derivative Mark . . . . . . . . . . . . . . . . . . . . . 11 81 5.10. Co-marketing . . . . . . . . . . . . . . . . . . . . . . 11 82 5.11. Franchisee . . . . . . . . . . . . . . . . . . . . . . . 12 83 6. Validator options . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1. Pros and cons of validation approaches . . . . . . . . . 13 85 6.2. Receiver Managed Reputation . . . . . . . . . . . . . . . 13 86 6.3. Remote Reputation . . . . . . . . . . . . . . . . . . . . 14 87 6.4. Centralized system . . . . . . . . . . . . . . . . . . . 14 88 6.5. Self validation . . . . . . . . . . . . . . . . . . . . . 14 89 6.6. Third Party Validation Publishing Options . . . . . . . . 15 90 6.6.1. Publishing validation: Certificates . . . . . . . . . 15 91 6.6.2. Publishing validation: API . . . . . . . . . . . . . 15 92 6.7. General Issues of Validation . . . . . . . . . . . . . . 16 93 7. Consuming the indicator . . . . . . . . . . . . . . . . . . . 16 94 7.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 9. Threats and Remediation . . . . . . . . . . . . . . . . . . . 17 97 9.1. Bad indicators . . . . . . . . . . . . . . . . . . . . . 17 98 9.2. Revoking Certificates . . . . . . . . . . . . . . . . . . 18 99 9.3. Geographic scope . . . . . . . . . . . . . . . . . . . . 18 100 9.4. IMAP flags . . . . . . . . . . . . . . . . . . . . . . . 18 101 10. Informative References . . . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 Brand Indicators for Message Identification (BIMI) provides a 107 mechanism for mail senders to publish a validated indicator, which is 108 typically a logotype, that mail receivers can display with the 109 senders' messages. 111 For senders, an indicator published with BIMI is available to any 112 recipient without having to make individual arrangements with each 113 recipient system. BIMI indicators are only displayed with messages 114 that are validated with DMARC [RFC7489]. For senders that want to 115 have their indicator displayed ("brand impression") this may provide 116 an incentive to make their mail streams DMARC compliant. 118 For mail systems that display indicators next to messages, BIMI 119 provides an automatic way to obtain indicators that have been 120 validated by third parties, without having to individually research 121 or contact each sender. 123 2. High level architecture and data flow 125 A sender publishes its indicator by putting a file containing the 126 indicator's image on the web, or possibly several images if they want 127 to show it in various forms. The sender may arrange for a third 128 party to verify that the sender is authorized to use the indicator. 130 The sender then publishes one or more DNS records with names like 131 selector._bimi.example.com, containing tags with the URIs of the 132 indicator(s), and URIs of validation information if any. If it wants 133 to associate different indicators with different messages, it can 134 publish several DNS records with the various indicator URIs, and the 135 message can pick a selector (see below.) 137 Then the sender sends mail the usual way, arranging for it to be 138 DMARC validated. If it wants to pick a particular indicator, a 139 message can include a BIMI-selector header to pick a particular 140 selector. Otherwise it implicitly uses the "default" selector. 141 (Note that this allows mail to use BIMI without having to include any 142 new BIMI material at all.) 143 The recipient system receives the mail and does DMARC validation as 144 usual. If DMARC passes, it does a DNS lookup of the BIMI record 145 using the DMARC validated domain and the appropriate selector. It 146 fetches the indicator(s) using the URIs in the DNS record, may check 147 the third party validation, and may make other checks to decide 148 whether the indicator is usable. 150 Assuming that all worked, the recipient system adds the usual 151 Authentication-Results header with the DMARC and BIMI validation 152 results, and a new BIMI-Location header that contains the URIs of the 153 indicator files to the message. An MUA, either one integrated into a 154 webmail system or a separate one, can use the BIMI-Location header 155 URIs to fetch the indicators to display to the user, per its own 156 policy. 158 3. Risks and problems of BIMI 160 BIMI inherently assumes that showing indicators with mail messages is 161 desirable, and standardizing how this is done is of value for senders 162 and perhaps for recipients. Some mail systems have been showing 163 logos and other per-sender images such as avatars or pictures of the 164 sender for a long time. 166 Since indicator validation requires human effort, there will always 167 be avenues to show indicators that are confusing or malicious. BIMI 168 attempts to contain those abuse vectors in its validation process and 169 ensure they are mitigatable at scale. Even assuming abuse is 170 successfully contained within the validation mechanisms, there are 171 other inherent risks and potential problems that could arise out of 172 the usage of BIMI if it is improperly architected or implemented. 173 Some of the most concerning are detailed below. The trade offs 174 between potential problems and benefits remains unclear. 176 3.1. Private club 178 Currently large mail systems show indicators of large senders using 179 fragmented methods to identify the senders' mail and the indicators 180 to use. One of the goals of BIMI is to open up the process to 181 organizations that don't have access to representatives of receiving 182 systems, or the ability to go through a separate process for each 183 receiver, but if implemented poorly, it just changes the secret 184 handshake. While many domains may publish validated logos via BIMI, 185 others will be unable to or intentionally decline to participate. 186 Similarly BIMI can identify some set of indicators to tie to senders, 187 but will never handle a complete set of validated indicators either. 189 Depending on DMARC means that only senders with their own domain can 190 use BIMI. It can't identify many small senders that share their 191 providers' mail domains, e.g., a girl scout troop using a single 192 address from their provider, such as troop42@bigisp.com, even though 193 the troop has a license to use the Scouts' trefoil logo. A modified 194 design could address this, described later. 196 Conversely, if the indicator has to be a registered trademark, that 197 limits BIMI to organizations big enough to pay for and maintain a 198 trademark registration (in the US typically several thousand dollars 199 to get a trademark, and several hundred dollars every few years for 200 maintenance.) Some countries have no trademark registries, or do no 201 meaningful examination, which means that people in those countries 202 are out of luck. On the other hand, if the indicator doesn't have to 203 be registered, see the next section. 205 3.2. Inconsistent validation 207 To the extent that BIMI has multiple validation methods, it will 208 produce different results on different mail systems. If systems use 209 their own reputation data to decide whose indicators to show, 210 indicators that appear on one system may not appear on another. If 211 there are third party validators (certificate authorities or the 212 like), there's no reason to assume that everyone will accept the same 213 set of validators, any more than every HTTPS client trusts the same 214 set of CA's. 216 Determining whether an indicator in an SVG file is the same as one in 217 a trademark registry is non-deterministic. The picture in a 218 trademark registry is typically a low resolution monochrome image. 219 (For example, see the copy of the IETF logo at 220 https://www.tmdn.org/tmview/trademark/thumbnail/US500000078755496). 221 There is no mechanical way to decide whether two images in different 222 resolutions and different sizes and colors drawn different ways are 223 "the same". At some point, people will have to look at them and 224 decide, and they will not always decide the same way. There is 225 limited existing practice to work from, primarily trademark 226 examination to determine whether a proposed trademark is 227 "substantially similar" to one registered elsewhere. Trademark legal 228 disputes are invariably about whether marks are likely to be 229 confused, not whether they are the same, and in any event the 230 resolution of the dispute generally involves lawyers and expert 231 witnesses. Dispute resolution about indicators is unlikely to work 232 at Internet scale. 234 For the vast numbers of organizations that don't have registered 235 trademarks, the problem is even worse since there's no agreed way to 236 find the reference mark to compare the indicator to. 238 And, of course, there's no guarantee that the third party validators 239 will be consistently honest, competent, and diligent. Experience 240 with certificate authorities suggests that is improbable. 242 3.3. Pay to Play 244 DMARC started with limited use to protect heavily phished domains, 245 with paypal.com being the usual example. As DMARC rolled out in 246 other fashions (such as AOL and Yahoo! using it to deal with address 247 book theft), it soon became widely used and increasingly required. 248 This is because DMARC is a fairly effective tool to deter exact 249 domain phishing attacks and email-borne fraud. However, DMARC has 250 proved difficult to deploy for many organizations. While there are 251 some free resources to help people get their DMARC set up, in 252 practice it means that businesses pay someone to make their DMARC 253 work. Similarly, although the current plan is for BIMI to be totally 254 optional, it's not hard to see it going down the same path, 255 especially if logo validation is perceived by senders as a signal to 256 receiving systems to help disambiguate fraudulent mail streams. Even 257 if there are paths to getting a validated BIMI indicator without a 258 full trademark registration, it's likely to be complex enough that 259 most organizations will need a consultant. Hence it would end up as 260 another expensive hoop to jump through just so you can send some mail 261 to your clients. 263 Even if you do your BIMI implementation yourself, third party 264 validators will not be free. Validation is labor intensive, both the 265 process of determining that your domain matches the organization that 266 owns the indicator, and the process of comparing the reference 267 indicator to the proposed indicator. If it's a derivative or 268 otherwise modified mark (the girl scout troop combines the trefoil 269 with a picture of a local landmark) the process is even more labor 270 intensive. The work is similar to what trademark examiners do, and 271 they are attorneys with experience in trademark law. 273 3.4. User Security 275 In the current draft, every time BIMI causes an MTA or MUA to fetch a 276 remote resource, whoever runs that resource can tell something about 277 the recipient. As noted below, fetches in the MTA right after the 278 message has been received leak relatively little, particularly on 279 large systems where the resources are likely to be cached locally. 280 Fetches from the URL in the BIMI-Location header are a definite web 281 bug. This can be fixed relatively easily as described later. The 282 risk here is with smaller mail systems or MUAs that do not have means 283 to cache the logos. 285 4. Indicator Publishing Options 287 The indicator(s) are published on the web as SVG files or potentially 288 other formats. 290 For a domain owner that wishes to assert a BIMI indicator, the 291 process must be as lightweight and transparent as possible. There 292 are multiple options, each with its own inherent value and threats, 293 that are possible to make this assertion. 295 4.1. Message header 297 BIMI indicators could be published by adding them in a new header 298 field in participating messages, along the lines of a validated 299 X-Face header. This mechanism is simple, but has several 300 disadvantages and threats: 302 o It requires all participating messages to have the header field; 303 which is neither lightweight nor transparent. 305 o It requires per-message validation of the header field, instead of 306 being cached at the domain level. 308 o It does not allow for the indicators to be pre-fetched and 309 validated in advance, which opens attack vectors from CGI scripts 310 and the like. 312 4.2. S/MIME signatures 314 In principle Indicators could be asserted through S/MIME 315 certificates. They don't share the same attack vectors as asserting 316 through a naked header field, and they're self-validating to the 317 extent the MUA trusts the signer. S/MIME is unlikely to work at 318 scale for a variety of reasons: 320 o Many senders don't have the skill to do the signing, 322 o major webmail systems don't interpret S/MIME signatures, 324 o and S/MIME certificates have all of the process issues of any 325 other certificates. 327 Requiring S/MIME for BIMI to function is neither lightweight nor 328 transparent for domain owners. 330 4.3. DNS assertion records 332 Publishing an assertion record in DNS has several advantages: 334 o There is exactly one mechanism for both simple and complex 335 policies to be published. 337 o Operational complexity is reduced, and MTAs only need to check a 338 single record per sending domain in a consistent manner to enforce 339 policy. 341 o Indicators can be verified and/or cached in advance, so that 342 malicious headers cannot be used as an attack vector. 344 o By publishing a single DNS record, the indicator can be consumed 345 by all receiving mail systems without needing to make any 346 modifications to the email in transit, allowing for transparency 347 regardless of the source of email. 349 o This looks and feels similar to a DMARC record, meaning a domain 350 owner that is already using DMARC is familiar with the mechanism 351 already. 353 The downsides and threats of publishing an indicator in the DNS are 354 that this requires BIMI be a domain-based standard, and can be 355 compromised if a domain's DNS is compromised or hijacked. 357 5. Validation Requirements 359 For an indicator to be considered validated, there must be a 360 confirmed mapping among organization, domains, and indicators. To 361 prevent fraudulent representation of any of this mapping, all of the 362 following criteria must be met: 364 o The organization is legitimate 366 o The domain names are controlled by the organization 368 o The party requesting validation is currently authorized to do so 369 by the organization 371 o The party requesting the validation is who they say they are 373 o The organization has current rights to display the indicator 375 The final requirement, that the organization has rights to display 376 the indicator, is fraught with nuance, and BIMI could become a vector 377 for phishing unless this is handled properly. What follows are the 378 different types of indicators an organization might wish to prove 379 they have the rights for, and how they can attest to those rights. 381 None of the below attestation of rights are full proof; meeting these 382 requirements does not mean a mail system will consider that 383 sufficient evidence to display the indicator. It is expected that 384 both validators and receiving systems will choose which of these use 385 cases they will support and which they will not. 387 5.1. Indicator Usage and Rights Validation Scenarios 389 There is a wide variety of ways that an indicator might be associated 390 with an organization and its domain(s), and how the association can 391 be verified. 393 The intent is not for a domain owner to know which of these use case 394 their indicator falls into and make a request accordingly, but for a 395 validator to make sure they use appropriate validation criteria, 396 given the type of indicator they are provided with. 398 Further, in the short term, validators may choose to only validate 399 indicators that can be verified using the highest standards, waiting 400 to verify more complicated use cases until they're certain of their 401 verification processes and confident they can prevent fraudulent 402 requests against new types of indicators. 404 5.2. Registered Mark 406 Usable when an indicator has been registered in a well known and 407 trustworthy jurisdiction. 409 To prove a logo is associated with the organization, the 410 registration, jurisdiction, issuance date, and expiration must be 411 provided, and the registrant of that mark must match the organization 412 requesting indication validation. 414 The problem with registered marks, beyond what is discussed in 415 Section 3.3, is that trademarks are not anti-phishing mechanisms. 416 Rather, they are anti-confusion mechanisms within tightly scoped 417 silos and jurisdictions, and they see frequent abuse and have slow 418 and costly remediation processes. 420 5.3. Registered Mark (untrusted jurisdiction) 422 When a registered mark in a jurisdiction that is untrusted is 423 provided, all the evidence should be reviewed, but validation should 424 proceed as if a Common Use Mark had been provided, not a Registered 425 one. 427 5.4. Common Use Mark 429 A widely used but unregistered indicator. Without providing for 430 Common Use Marks, BIMI will certainly become a private club. This 431 is, however, the most difficult use case to provide rights for. You 432 must prove active usage of the indicator in the real world, and 433 provide documentation showing that the rights to the logo have been 434 properly assigned to your organization. 436 The threat here is cousin or lookalike marks. While BIMI has no 437 direct protections for lookalike marks, allowing for Common Use Marks 438 makes it far easier to validate such a mark. 440 5.5. Common Use Mark (untrusted jurisdiction) 442 Validation similar to above. 444 The threat in untrusted jurisdictions for lookalike or cousin domains 445 is much higher. 447 5.6. New/Rebranded Mark 449 A Registered or Common Use Mark that is not in wide enough use to 450 pass the Common Use requirements. 452 Many organizations come out with new products or wholly rebrand from 453 time to time. These common changes should be able to be reflected in 454 BIMI, or systems that displayed BIMI indicators could be out of date 455 for significant period of time until Common Usage could be proven or 456 even longer until a registration was completed. 458 Validation is the same as for Common Use, but instead of proving 459 usage in the real world, you must prove intent to use. 461 The threat here is that there is that bad actors could attempt to use 462 this use case to validate arbitrary logos. 464 5.7. Mildly Altered Mark 466 For an indicator to look good within a BIMI context sometimes mild 467 changes are required (i.e. to take a long logo and stack it so that 468 it will fit within a square, to remove a background color, etc.). 469 Specifically, a Mildly Altered Mark is a logo of one of the preceding 470 types of marks that has been altered minimally (recolored, cropped, 471 rotated, stretched, or reformatted or sliced and repositioned to fit 472 in a different aspect ratio). These mild modifications aren't new 473 indicators worthy of registration or wouldn't pass common usage tests 474 of their own. 476 To validate a mildly altered mark, you must validate the unaltered 477 mark, and the validator must further attest that the modifications 478 are minimal per the above list and only for the purpose of working 479 better within a BIMI context. 481 The threat with mildly altered marks is that any defenses depending 482 on automated detection will be confused by the alterations, which bad 483 actors would presumably take advantage of. Further, this relies on a 484 human saying that an alteration is mild, which different people will 485 do differently. 487 5.8. Multiple Marks 489 A logo comprised of more than one of the preceding types of marks, 490 all from the same organization, with one or more marks potentially 491 obscured by others. 493 Validation requires validating each primary mark individually, and 494 the validator attesting that any obscured mark is still 495 distinguishable at its original self. Again, automated detection 496 could be confused by this, which bad actors can take advantage of. 497 It is also possible that obscured marks could be a vector to create 498 confusable indicators. 500 5.9. Derivative Mark 502 A logo comprised of more than one of the preceding types of marks, to 503 which new imagery has been added, potentially obscuring the initial 504 mark(s). Derivative marks are common, as organizations frequently 505 slap other images on top of their logos, such as in seasonal or 506 geographic campaigns. Providing this functionality dramatically 507 expands the approachability of BIMI for many organizations' needs. 509 As with Multiple Marks, anything that obscures the original mark 510 could create a new confusable indicator. 512 5.10. Co-marketing 514 Multiple marks or derivative marks, but from separate organizations, 515 where there is joint permission for use. This occurs frequently with 516 partnerships. 518 Validation is the same as for multiple marks, but each organization 519 must prove all validation requirements for its mark, and all 520 organizations must provide proof that their indicator can be used in 521 conjunction with the other. The expiration of the co-marketing must 522 also be provided for. 524 Validating a co-marketing indicator would likely depend on validating 525 the underlying marks first. 527 Threats here are again related to one indicator obscuring another, or 528 two marks being put together in such a way as to become confusable 529 with a more well known one. . 531 5.11. Franchisee 533 It is common for an organization to have the rights to display an 534 indicator without being the owner of the indicator. 536 To validate this, the initial indicator must be validated, and the 537 franchisee must prove they have the rights to display and prove they 538 are in good standing with the licensor and those rights have not 539 expired. 541 The indicator would likely have to be validated by its owner before 542 franchisees can be granted their own validated indicator. 544 Threats are franchisees who were legitimate when they got the 545 indicator validated, but then lost standing and continued to use the 546 indicator. 548 6. Validator options 550 There are multiple ways that a recipient system might validate a 551 logo. 553 o Third party validation: a mutually trusted third party attests 554 that the domain is authorized to use the logo. There are various 555 ways the third party could publish the attestation. 557 o Local reputation: large systems track sender reputation, and could 558 accept logos for senders with good reputations. 560 o Remote reputation: There might be a shared reputation service, or 561 receivers could use sender characteristics like a domain in a TLD 562 such as .BANK or .NGO that limits registrants to known 563 Organizations. 565 o Self validation: some systems know their own customers and/or are 566 whitelist based, and may not require validation for published BIMI 567 indicators so long as DMARC passes. 569 6.1. Pros and cons of validation approaches 571 Third party validator 573 Pros: 575 o Scalable solution that takes much of the burden off of senders and 576 receivers 578 o Senders bear a predictable cost for vetting, rather than receivers 579 bearing the bulk of the burden, which allows smaller receivers to 580 participate 582 o More flexibility and lower technical bar for domain owners 584 Cons: 586 o Some cost component (e.g. senders still have to pay.) 588 o Does not exist today; (almost) entirely new. 590 o Smaller receivers may not be able to tell which third parties are 591 reliable. 593 6.2. Receiver Managed Reputation 595 Pros: 597 o If a receiver already trusts a brand, validation may be more 598 straightforward 600 o Easy to set up; no additional steps on the sender side 602 Cons: 604 o Impractical for smaller receivers due to lack of adequate local or 605 shared reputation data. 607 o Reputation can be gamed. 609 o Lack of transparency and consistency 611 o Smaller senders may not send enough mail to generate trust data. 613 6.3. Remote Reputation 615 Some registries limit registrants to verified members of a group such 616 as NGOs, co-ops, or banks. 618 Pros: 620 o Leverage existing validation at TLDs or similar groups. 622 o Easy to use, just see if the domain's in a validated name tree. 624 Cons: 626 o Limited coverage 628 o Unknown and highly variable quality of remote reputation 629 validator. (Some TLDs only validate at application time, never 630 check again later.) 632 6.4. Centralized system 634 Similar to government, e.g. USPTO, JIPDEC 636 Cons: 638 o Risk of too much concentration of power, too slow in terms of 639 responsiveness to customers and ability to execute, lack of 640 incentives. 642 6.5. Self validation 644 Pros: 646 o No overhead to publishing an indicator 648 Cons: 650 o No validation; no assurances about indicator 652 o Too easy to publish fraudulent indicators 654 o No meaningful way to evaluate as a receiving system unless the 655 domain is on a whitelist, in which case it's like remote 656 reputation. 658 6.6. Third Party Validation Publishing Options 660 Once a third party has validated an indicator, how can it tell 661 consuming systems about it? 663 6.6.1. Publishing validation: Certificates 665 A third party validator could act as a CA and sign certificates that 666 contain the sender's domain and logo, or for large logos perhaps a 667 hash of the logo. See [BIMICERT]. 669 Pros: 671 o Open standard, well defined and understood 673 o Costs borne by sender, certificates published by sender. No 674 centralized trusted authority that may fail catastrophically 676 o Technical security of certificates is well understood 678 o Certificate Transparency could be utilized, including 679 prepublication for challenge. 681 Cons: 683 o CAs have ongoing history of mismanagement, lack of trust and 684 responsiveness. 686 o Revocation doesn't really work. (See below Section 9.2.) 688 6.6.2. Publishing validation: API 690 Third party validator could provide an API where receivers could send 691 queries with the domain and indicator and get back yes or no, or 692 perhaps send the domain and get back a list of indicator hashes. 694 Pros: 696 o Doesn't depend on CAs. 698 o Revocation is easy. 700 o More flexible than certificates (easier to add or remove domains 701 that an indicator is validated for) 703 Cons: 705 o Doesn't exist yet, needs to be defined, implemented, and 706 discoverable. 708 o Easily subverted into closed club or expensive (to receivers) 709 service. 711 o Could end up with many of the same issues that CAs have 713 6.7. General Issues of Validation 715 Is there a reproducible way an authority can decide whether a 716 proposed SVG image is close enough to an image in a registry that is 717 likely lower resolution and not in color? Does the expertise exist 718 and if so is it widespread enough to support an adequate number of 719 validation organizations? 721 How if at all to audit validation. CT logs or the like could 722 prepublish certificates, and log all issued certificates to aid in 723 forensics in case of mistakes. 725 How is conflict of interest handled? If third parties are paid to 726 validate, what is their motivation to turn away business when that 727 business appears to be fraudulent? 729 7. Consuming the indicator 731 The MTA fetches the certificate(s) and indicator(s) using the URIs in 732 the DNS record, and checks the validation. 734 Assuming that all worked, the recipient adds a new BIMI-Location 735 header to the message that contains the URIs of the indicator files. 737 7.1. Issues 739 If MUAs fetch the indicator using a URI in the BIMI-Location header, 740 that's a web bug with privacy issues. If the MTA put a copy of the 741 actual indicator as a data: URI in the header rather than an https 742 pointer, that would solve the web bug problem and would also make the 743 MUA faster. If data: is too bulky, the MTA could cache the indicator 744 and put a local URL in the header. The MTA still has to fetch the 745 indicator when the message is received, but since the message has 746 just arrived, the sender knows the message has been received. Since 747 the indicator fetch is by the MTA before the message is delivered, 748 the sender can't use the indicator fetch to tell when the user looks 749 at it in an MUA. The sender may be able to use the fetch to tell 750 that the message got far enough to be worth BIMI validation. 752 8. Reporting 754 BIMI currently has no provision for reporting its use, but indicator 755 publishers say they want it. 757 o It must not be a mechanism for tracking whether messages were 758 delivered or opened. Caching certificates and indicators helps 759 here. 761 o It must not be a mechanism for exposing the internals of mail 762 systems, e.g, by leaking data about what of messages were 763 delivered vs not. 765 One possibility would be a BIMI tag similar to DMARC reporting tags 766 that reports how many BIMI eligible messages for a domain were 767 received, but not what the MTA did with them. 769 9. Threats and Remediation 771 BIMI should have some mechanism for remediating problems that one 772 receiver sees to make that available to all consumers in a timely 773 manner. 775 9.1. Bad indicators 777 An obvious threat is that a corrupt or incompetent validator approves 778 a indicator that a domain owner shouldn't display. There are two and 779 a half somewhat different scenarios here: 781 1. The actual owner of the domain gets a validation with his domain 782 and someone else's indicator. 784 2. A malicious third party tricks a validator into approving a 785 totally fraudulent validation for someone other than the owner of 786 the domain involved. 788 3. A malicious third party tricks a validator into validating an 789 indicator with a lookalike domain (ub3r.com vs. uber.com). 791 The second scenario doesn't seem important, because you can't use the 792 certificate unless you can send DMARC aligned mail, which you can't 793 do unless you control the actual domain's DNS. (If the bad guy can 794 take over your DNS all bets are off.) 796 9.2. Revoking Certificates 798 If BIMI validations are published with certificates, sometimes the 799 validations will be wrong and a certificate will need to be revoked. 800 As has been widely observed, certificate revocation has never worked 801 very well. But since this would be a fairly unusual application of 802 certificates, maybe some other approaches would work if the 803 validators issue certificates: 805 1. Taking a tip from Let's Encrypt, reissue the certificates every 806 week. Another possibility would be some sort of stapling, but if 807 the CA has to do something anyway, it might as well reissue 809 2. Serve the certificates from the CA rather than from the sender. 810 (Put something in the certificate that has to match the domain in 811 the URI used to fetch it.) Then if the certificate turns out to 812 be bad, the CA can stop serving it. This is essentially the API 813 approach, but serving certificates rather than hashes. Or under 814 the assumption that most unexpired certificates are still good, 815 perhaps just send a hash of the certificate and get back an 816 answer whether it's still good, which is a lot less data. 818 3. Since the certificates will be validated in tens of thousands of 819 MTAs rather than in a billion PCs and phones, some sort of 820 revocation list that doesn't scale to a billion might still scale 821 to tens of thousands. 823 9.3. Geographic scope 825 Trademarks and indicators have geographic scope. A BIMI certificate 826 could presumably have a list of country or other geographic codes but 827 what is the recipient supposed to do with them? Does the MDA attempt 828 to know where its users live? Does the code go into the BIMI- 829 Location header (or in a certificate the header points to) so the MUA 830 on my phone shows me different indicators in New York or Paris? This 831 is a user interface issue beyond the protocol, but there should be a 832 plausible story that could calm the lawyers who'd be signing off on 833 indicator publication. 835 9.4. IMAP flags 837 BIMI invents a flag for IMAP that the MDA can set on a message to 838 mark that the BIMI-Location header is real. It presumably stays with 839 the message if it's moved to other folders. This opens a narrow 840 abuse channel if a malicious IMAP client can put messages with fake 841 BIMI-Location headers and the IMAP flag, but if your client can do 842 that, you will have far worse problems than bogus MUA indicators. 844 An alternative approach would be for the MDA to add a DKIM signature 845 with recipient system's d= that includes the new BIMI-Location header 846 and the MUA can check that signature to decide whether to believe it. 847 This would require some careful sanitizing to prevent spoofing but I 848 think it's doable. 850 10. Informative References 852 [BIMICERT] 853 Chuang, W., Ed. and T. Loder, Ed., "Brand Indicator for 854 Message Identification in X.509 certificates", internet- 855 draft draft-chuang-bimi-certificate-00.txt, May 2018. 857 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 858 Message Authentication, Reporting, and Conformance 859 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 860 . 862 Authors' Addresses 864 Seth Blank 865 Valimail 867 Email: seth@valimail.com 869 Neil Kumaran 870 Google 872 Email: nmk@google.com 874 John Levine (editor) 875 Standcore LLC 876 PO Box 727 877 Trumansburg, NY 14886 879 Phone: +1 6465701224 880 Email: standards@standcore.com