idnits 2.17.1 draft-chuang-ietf-bimi-security-perspectives-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 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1871 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 756 -- Looks like a reference, but probably isn't: '2' on line 759 -- Looks like a reference, but probably isn't: '3' on line 761 -- Looks like a reference, but probably isn't: '4' on line 763 -- Looks like a reference, but probably isn't: '5' on line 765 -- Looks like a reference, but probably isn't: '6' on line 767 -- Looks like a reference, but probably isn't: '7' on line 770 -- Looks like a reference, but probably isn't: '8' on line 772 -- Looks like a reference, but probably isn't: '9' on line 774 -- Looks like a reference, but probably isn't: '10' on line 777 -- Looks like a reference, but probably isn't: '11' on line 779 -- Looks like a reference, but probably isn't: '12' on line 781 -- Looks like a reference, but probably isn't: '13' on line 784 -- Looks like a reference, but probably isn't: '14' on line 786 -- Looks like a reference, but probably isn't: '15' on line 789 -- Looks like a reference, but probably isn't: '16' on line 792 -- Looks like a reference, but probably isn't: '17' on line 796 -- Looks like a reference, but probably isn't: '18' on line 798 -- Looks like a reference, but probably isn't: '19' on line 800 -- Looks like a reference, but probably isn't: '20' on line 803 -- Looks like a reference, but probably isn't: '21' on line 807 -- Looks like a reference, but probably isn't: '22' on line 809 -- Looks like a reference, but probably isn't: '23' on line 812 -- Looks like a reference, but probably isn't: '24' on line 815 -- Looks like a reference, but probably isn't: '25' on line 817 -- Looks like a reference, but probably isn't: '26' on line 820 -- Looks like a reference, but probably isn't: '27' on line 823 == Unused Reference: 'RFC5280' is defined on line 711, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3709 (Obsoleted by RFC 9399) ** Obsolete normative reference: RFC 6170 (Obsoleted by RFC 9399) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) == Outdated reference: A later version (-02) exists of draft-blank-ietf-bimi-00 == Outdated reference: A later version (-09) exists of draft-brotman-ietf-bimi-guidance-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Area Working Group W. Chuang, Ed. 3 Internet-Draft Google, Inc. 4 Intended status: Informational T. Loder, Ed. 5 Expires: September 12, 2019 Skye Logicworks 6 March 11, 2019 8 Verified Mark Certificates Proposal: A Security Perspective 9 draft-chuang-ietf-bimi-security-perspectives-00 11 Abstract 13 This document motivates the need for embedding logotypes in X.509 14 certificates along with the certificate validation process from a 15 security perspective. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 12, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Critique of the BIMI Proposals . . . . . . . . . . . . . 3 53 1.1.1. BIMI Draft . . . . . . . . . . . . . . . . . . . . . 3 54 1.1.2. BIMI Guidance (So far) About Certificates . . . . . . 5 55 2. Verified Mark Certificate . . . . . . . . . . . . . . . . . . 7 56 2.1. Certificate Association With Logo . . . . . . . . . . . . 7 57 2.2. Verified Identity of Sender . . . . . . . . . . . . . . . 8 58 2.3. Root Program . . . . . . . . . . . . . . . . . . . . . . 8 59 2.4. Certificate Transparency . . . . . . . . . . . . . . . . 9 60 2.5. Registered Trademark . . . . . . . . . . . . . . . . . . 10 61 2.5.1. Coexistence with non-Registered Trademark . . . . . . 11 62 2.6. Logo Image Format . . . . . . . . . . . . . . . . . . . . 11 63 2.7. Non-Display of Logo . . . . . . . . . . . . . . . . . . . 12 64 2.8. BIMI Message Fetch . . . . . . . . . . . . . . . . . . . 12 65 2.8.1. Mail Clients Support . . . . . . . . . . . . . . . . 12 66 3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.2. X.509 Message Authentication Proposal . . . . . . . . . . 14 69 4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 5. Conventions Used in This Document . . . . . . . . . . . . . . 15 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 6.2. Informative References . . . . . . . . . . . . . . . . . 16 74 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Objectives 79 Many Mail User Agents and mail systems provide logo imagery as 80 avatars as part of the user interface chrome. For branded email, the 81 agents and systems use different, proprietary methods for 82 provisioning the avatar which causes consistency problems. Instead 83 there should a common, internet scale, secure method to fetch the 84 sender's brand logo indicators during message delivery which this 85 document along with others documents by the AuthIndicators Working 86 Group (aka BIMI Working Group) propose. 88 Given the potential for impersonation abuse if not safeguarded, the 89 proposal incorporates defense in depth as it assumes an adversarial 90 security model and that parties will attempt to exploit sender/ 91 subscribers for their own criminal benefit. Due to this risk of 92 identity spoofing, a sender's identity is verified by a Certificate 93 Authority (CA) that acts as a Mark Verification Authority (MVA) that 94 then issues X.509 certificate with this evidence as a Verified Mark 95 Certificate (VMC). One risk is that the MVA may fail to distinguish 96 a spoofed identity during their verification either by oversight or 97 intentionally. To enable detection, issued certificates are publicly 98 disclosed through permanent untamperable logs that can be verified by 99 receivers, trademark monitors, the trademark holders themselves, and 100 other interested parties. Because of this, email receivers will have 101 greater confidence that the sender's logo is what the sender says 102 they are. 104 The logo may be presented to the recipient if the email is at a 105 minimum authenticated via SPF [RFC7208], or DKIM [RFC6376], and 106 passes the DMARC [RFC7489] policy check. Because this proposal uses 107 domain authentication and DMARC in order for the logo to be shown, it 108 incentivizes the use of these domain authentication and authorization 109 methods. These methods are important because they provide a 110 consistent means of protecting against an sender domain spoofing. 111 However the FTC Office of Technology Research and Investigation in 112 2017 found that 66% of business mail domains did not use DMARC. Logo 113 carrying mail must also pass other receiver requirements such as not 114 phish and not spam per their own policies. Domain-based 115 authentication methods SPF, and DKIM, enables the email receivers' 116 automated anti-abuse systems to tie together emails sent by the same 117 sender to generate accurate per domain reputations that allow them to 118 filter abusive emails. The Verified Mark Certificate contains 119 curated sender's metadata, that provides additional signals for anti- 120 phishing. 122 This document builds on the more generalized brand logo association 123 drafts that is specified in [I-D.blank-ietf-bimi] and 124 [I-D.brotman-ietf-bimi-guidance]. This document is meant to motivate 125 the purpose for Verified Mark Certificates, and is purely 126 informative. The Roadmap (Section 4) section calls out where 127 normative documents are needed. 129 1.1. Critique of the BIMI Proposals 131 1.1.1. BIMI Draft 133 The [I-D.blank-ietf-bimi], dated February 6, 2019 aka the "Assertion 134 Record" specification, states as its objectives the following goals: 136 o No dependency on new Internet protocols or services for indicator 137 registration or revocation 139 o Incremental deployment 141 o Policies solely published in BIMI DNS (TXT) record 143 o Delegation by logo owners to third party logo providers 144 o Scalability of brand associations across internet scale of domains 146 o Uniformity of brands displayed 148 (BIMI stands for Brand Indicators for Message Identification) The 149 Assertion Record draft uses SPF/DKIM/DMARC for message verification. 150 It defines optional header metadata and defaults to determine from 151 where to fetch the logo policy and locator from BIMI DNS TXT records. 152 From these, the receiver can generate a URL to fetch the logo. It 153 succeeds with the above goals, however it admits an important 154 limitation in that it does not specify "verification and reputation" 155 mechanisms and depends on them to prevent abuse. This document 156 describes solutions for those limitations. 158 1.1.1.1. BIMI Draft Threat Modeling 160 Because some of the uses of branded email are high-value 161 transactional and business emails, there is the possibility the 162 protocol might be abused. Consequently the following is a threat 163 model to identify security weaknesses in the above protocol. 164 Malicious senders may spoof trusted identities for phishing or spam 165 by copying brand identities or by creating a similar but confusable 166 logo, served from their domain with their own domain authentication. 167 A adversary could: 169 o game the receiver's reputation system by using automated networks 170 [1] to send good email traffic and then launch an attack. 172 o related concern, is the problem of low traffic senders that 173 receivers will have difficulty determining reputation. 175 An explicit definition of trustworthiness may be helpful establishing 176 a reputation in these circumstances. 178 Another attack is to exploit the vulnerability of the email system by 179 injecting emails crafted by the adversary that use the good sender's 180 identity. While BIMI uses message authentication through SPF/DKIM/ 181 DMARC that is meant to prevent this type of spoofing, the adversary 182 could exploit domains with weak authentication via: 184 o overly broad SPF [2] policies acceptance policies 186 o weak DKIM keys [3] 188 Fortunately good senders can easily fix this. The adversary could 189 exploit weaknesses in DNS integrity as message authentication depends 190 on the integrity of the SPF/DKIM/DMARC records which may be attacked 191 through DNS cache poisoning or man-in-the-middle (MitM). While such 192 attacks seem far fetched, the Snowden disclosures [4] show that 193 nation-state adversaries have been able to mount such attacks. 194 Unfortunately deployment of DNS protection through DNSSEC seems to be 195 stalled [5]. 197 1.1.2. BIMI Guidance (So far) About Certificates 199 The [I-D.brotman-ietf-bimi-guidance] dated on 6 Feb 6 2019 aka 200 "Receivers Guidance" extends and provides best practices for the 201 Assertion Records draft. It notes the use of Verified Mark 202 Certificates which is new certificate issued by Mark Verifying 203 Authorities (MVA) to resist the spoofing attacks though with limited 204 details on validation and usage. The Receivers Guidance document 205 states receivers should work with multiple MVAs to allow the 206 successful untrust of any one malicious MVA. It also calls for 207 receivers to partner with Dispute Resolution Agencies to handle 208 trademark conflicts as well as acknowledges the courts primacy for 209 conflict resolution. It has other guidance: it notes that receivers 210 MTA may fetch and store the logo for the MUA or it may have the MUA 211 fetch it itself. It also provides deployment guidance on domain 212 authentication and DMARC. 214 The Receiver Guidance document references an AuthIndicators Working 215 Group document "Verified Mark Certificates Usage (for review)" [6] 216 dated 23 October 2018 for details about Verified Mark Certificates. 217 That document is a specification on the handling of Verified Mark 218 Certificates by the receiver MTA and recipient MUA. It defines the 219 VMC validation and fetch process designed to protect the privacy for 220 the recipient from the sender- VMC fetch occurs at delivery time, and 221 cached by the MTA for use by the MUA, thus view time usage of the VMC 222 is hidden from the sender. Similarly Certificate Revocation Lists 223 (CRLs) are specified to allow for offline revocation checking of the 224 certificate. (There is the related scenario of keeping private the 225 use of the VM Certificate content by the recipient from the receiver. 226 This hasn't been specified in any of the documents, but a likely 227 solution would be embed the logo as a new header for use by the MUA) 229 Notably those two documents avoid detailed discussion on the use of 230 Verified Mark Certificates for which this document tries to fill in. 231 Moreover, there are potential operational risks with using curated 232 information provided by X.509 certificates that this document 233 discusses next. 235 1.1.2.1. Problems with Certificates 237 Experience using identity carrying certificates have identified 238 several important issues. An adversary attempting to spoof an 239 identity might try to exploit weaknesses in certificate issuance 240 validation. 242 o Lax or intentionally malicious validation by CA/MVA may allow an 243 adversary to impersonate with a copied or look alike identity. 245 o Ambiguities in the registered identity that the CA/MVA checks 246 against may allow an adversary to obtain an "legitimate" identity 247 for spoofing. Note that arguably the CA/MVA validation is 248 considered successful here. 250 * Carroll [7] demonstrated in 2017 that ambiguities caused by 251 different jurisdictions allowed him to obtain a web EV 252 certificate for "Stripe, Inc." in Kentucky that could have 253 allowed him to spoof the better known "Stripe, Inc" in 254 Delaware. While browsers displays differences in country 255 jurisdiction, it does not show state level information, and 256 even if it did, it is doubtful users would notice. The analog 257 for logos is that an adversary that desires spoofing logos in 258 one jurisdiction would register similar or identical logos in 259 another. 261 * Burton [8] similarly demonstrated that he could obtain a web EV 262 certificate for a misleading company name with a positive 263 sounding security message e.g. "Identity Verified". The 264 analog logo attack might be that the adversary registers a 265 checkmark or padlock logo. 267 * "Cousin marks" are similar but legitimate logos add another 268 dimension of confusability as illustrated by this list [9]. 269 This confusability of this list seems to be caused by the 270 trademark registration agency allowing similar logos when the 271 company's line of business don't overlap. 273 With these spoofing attacks, one issue has been understanding the 274 scope of the attack i.e. given one bad certificate, if there are 275 other ones. Lack of global visibility in what has been issued has 276 historically made this problematic. 278 The largest deployed set of these identity carrying certificates has 279 been web Extended Validation (EV) where the subscribers legal 280 identity gets additional validation. Web sites uses these EV 281 certificates get additional chrome e.g. historically a green "bar" 282 containing the company name and padlock indicator. However 283 operational experience has indicated problems with this approach: 285 o Jackson et al. [10] found that using the web EV green padlock UI 286 as a positive security indicator was not effective in helping 287 users distinguish good websites from phishing as users did not 288 notice the indicators. 290 o Company names sometime are not familiar to users. For example 291 Google's parent company name is "Alphabet Inc" which likely isn't 292 as familiar as "Google". 294 2. Verified Mark Certificate 296 This section specifies issuing a BIMI-specific X.509 certificate that 297 binds logos and other information to domains and to a legal entity. 298 CA/MVAs validate the binding and the X.509 CA based PKI proves to all 299 parties that this validation was done. These certificates are called 300 Verified Mark Certificates (VMC or VM Certificates aka Mark Verified 301 Certificates or MVC in some of our other documents). This document 302 primarily works with the use of registered trademarks as it provides 303 a useful legal framework to establish VMC upon, however the 304 AuthIndicators working group is evaluating how to expand that to 305 include other non-registered identities. 307 2.1. Certificate Association With Logo 309 Existing work provides specification for brand logos in X.509 PKIX 310 certificates as specified in [RFC3709] and [RFC6170]. The logo 311 images can be embedded within the X.509 certificate as a subject 312 extension [RFC3709] using a DATA URL mentioned in [RFC6170] and 313 specified in [RFC2397]. The certificate subject identifier describes 314 a legal owner of the brand that can be used for verification, and a 315 DNS domain that matches the sender's email address domain. The 316 validation of these identities can follow the procedures in CABF EV 317 baseline 1.6 [11] with additional guidelines specific for BIMI as 318 described in these Guidelines for Issuance of Verified Mark 319 Certificates v0.97 [12]. 321 The Verified Mark Certificate must chain-up to a well known public 322 trust anchor i.e. a well known Certificate Authority certificate 323 issuer. This provides a cryptographic means to prove that a domain 324 owns a brand to the relying party as long as they can trust the 325 transitive issuing policy. If the logo bearing certificate is a CA 326 certificate, then it must be name constrained to the owning domain or 327 subdomain. This prevents the brand from being wrongly associated 328 with some non-owning domain for some child entity certificate issued 329 from the CA certificate. [RFC3709] allows the specification of only 330 one logo per certificate. The issuer may need to issue multiple 331 certificates that bear different logos for the brand. The 332 appropriate logo is optionally selected by the BIMI email header as 333 mentioned in [I-D.blank-ietf-bimi] or defaults to the default for the 334 organizational domain name. 336 2.2. Verified Identity of Sender 338 The Verified Mark Certificate issuance process builds upon the web 339 Extended Validation (EV) [13] certificates issuance guidelines, with 340 appropriate extensions as described Guidelines for Issuance of 341 Verified Mark Certificates v0.97 [14]. In particular the brand 342 ownership must undergo rigorous validation by the issuing CA back to 343 that legal entity, including explicit face-to-face identity 344 validation of the applicant. CAs already have experience validating 345 internet domain ownership back to legal entities for the web EV 346 program, and it would be reasonably feasible for them to examine 347 brand IP as well since these may be registered in government 348 trademark registries i.e. the logos must match a registered trademark 349 as described later. In addition brand names may also be specified 350 and found in those registries, as often they are more easily 351 recognized than the owning company's name. CAs performing these 352 additional vetting steps would act as the Mark Verifying Authorities 353 (MVA) mentioned earlier. Further, the requesting party for the 354 certificates must meet certain minimum identification and formation 355 requirement e.g. be an incorporated company, government body or 356 registered non-profit known in the public record. The requesting 357 party's legal address is disclosed in the certificate for 358 identification by the recipient and other interested parties 359 following the practices of the trademark jurisdiction. For example 360 here's the link to USPTO [15] FAQ, and the link for EU [16] (on page 361 3). This also in some hopefully limited circumstance may help an 362 aggrieved party serve legal notice. 364 In summary the VMC Guidelines validation process proves that: 366 o Legal entity is legitimate 368 o Domain names are controlled by the organization 370 o Person requesting the certificate 372 * Duly and currently authorized to do so by the organization 374 * Who they say they are 376 o Legal entity has the rights to display the trademark logo (design 377 mark) and optionally name (text mark) 379 2.3. Root Program 381 BIMI-aware email receivers and/or mail clients should maintain their 382 own trusted BIMI CA/MVA root certificate store programs, or otherwise 383 rely on a program by another receiver. Such programs would manage a 384 fixed set of BIMI root certificates managed much like browser root 385 certificates. Most importantly these BIMI root certificate set 386 owners must create a security program to monitor the performance of 387 CA/MVA to adhere to their CPS much like the browser programs. A 388 fixed root certificate set creates certainty for the sender and 389 recipients and mitigates some BIMI header attacks. Certain receivers 390 could publish their root CAs, which would make it possible for 391 intended certificate subscribers to identify supported CAs. It also 392 moves much of the security work to the email receivers from the 393 sender, which are better positioned to do this work due to their 394 security staffing and association with browser security teams (with 395 their expertise in X.509 PKI security). 397 2.4. Certificate Transparency 399 We also propose that these certificates be published in Certificate 400 Transparency logs [RFC6962] analogous to those operated for web EV 401 certificates. Certificate Transparency (CT) logs are append only 402 which provides protection against equivocation i.e. manipulating the 403 logs to show different views to different requesters. A VM 404 Certificate proves that it is published in a CT log by including a 405 SCT extension generated when logged. All relying parties must check 406 for the presence of the valid SCT, and reject the certificate if it 407 is not present. Mandatory publishing provides global transparency 408 that makes it easier to detect other similar impersonation attacks or 409 mis-issuance. Global transparency provides certainty once a problem 410 has been detected that it can be fully remedied and contained. 412 While RFC3709 may allow an external logo with a secure hash which may 413 be convenient, an adversary may simply not supply potentially 414 incriminating logo during an investigation. Instead we propose 415 embedding the logos in the Verified Mark Certificate. With this the 416 VMC CT log also provides a catalog of curated logos and their 417 ownership in a machine readable form that may then be used by anti- 418 abuse systems for use as reference identities. 420 This document proposes that the major mail systems using VMC along 421 with VMC issuing CAs should run their own publicly visible CT logs. 422 While logging may be done collaboratively, there must always be 423 enough diversity so that multiple logs are available under separate 424 ownership to prevent conflict of interest. Mail systems can elect to 425 require logging to their CT log in order to show the logos. 427 While some companies (e.g. Google) already actively monitors the CT 428 logs for misissuance, many companies don't that should monitor CT 429 logs. This document encourages the development of log monitoring 430 services in particular visual logo monitoring to protect brands from 431 spoofing. For example, it is conceivable that a CA may be interested 432 in providing issuing and monitoring service for brands as part of 433 their commercial offering. Along those lines there are companies 434 specialized in mark monitoring e.g. MarkMonitor [17] that might be 435 interested. Automated visual recognition of logos is a capability 436 commercially available e.g. top 8 list [18]. 438 Beyond that we also propose research into pre-publication of the 439 certificate in the CT logs before issuance that allows trademark 440 monitors to detect and block issuance if necessary. These monitors 441 would follow the log to look for trademark infringement, improperly 442 created certificates, and other abuses, and can file complaints to 443 the log. If the conflict is not initially resolved between the 444 parties on he log, then the trademark owners have access to the 445 courts. Assuming the research into CT with preview, which is being 446 investigated by the AuthIndicators working group, proves its 447 feasibility, this can potentially be followed up with standards work. 449 2.5. Registered Trademark 451 Using registered trademark helps clarifies ownership of the logo, and 452 raises the difficulty of succeeding at impersonation. The 453 registration process in many jurisdictions requires that the 454 trademark be distinctive and non-confusable with another. To enforce 455 this, many jurisdictions use a public review period and brands 456 already employ brand monitors [19] to protect the trademarks. As 457 part of this review, many jurisdictions have tests for objectionable 458 or deceptive marks e.g. "Identity Verified". It also provides a 459 central authority that documents existing trademarks where an issuing 460 CA/MVA can match the submitted embedded logo to the documented 461 trademark. If there is a dispute between non-fraudulent parties, 462 registration provides access to the courts, and consequently 463 trademark conflict resolution becomes a process of following the 464 court process. The certificate identifies the trademark owner in 465 case it is necessary to start those legal proceedings. 467 One issue is jurisdiction as trademarks laws and practices differ. 468 This proposes that the smallest scope should be nation level where 469 trademark law is well established. Trademarks may also be registered 470 internationally (across 90+ countries) via the Madrid union and due 471 to the universal first world coverage of the Madrid union and largely 472 the rest of the world, such a trademark can be considered global 473 jurisdiction. Similarly well known regional, multi-country 474 jurisdictions e.g EU should be distinguishable as well. The country 475 code information can be specified in the certificate trademark 476 jurisdiction field. Display of the brand logo/name information 477 should follow where the information is valid, and this can be done by 478 displaying the logo only when the client is within the jurisdiction 479 to the best of the client's ability e.g. GPS on mobile devices, and 480 IP geolocation on desktop computers. A second closely related issue 481 is the strength of a particular jurisdiction trademark review and 482 legal system to prevent fraudulent trademarks. A concern is that 483 they may differ in their ability to prevent spoofing. The 484 AuthIndicators Working Group in conjunction with the CA/MVA and mail 485 systems will review and publish findings on the strength of 486 particular jurisdictions. International cross border registration or 487 multiple jurisdiction registration maybe helpful when some countries 488 have better trademark databases than others and should be encouraged. 490 2.5.1. Coexistence with non-Registered Trademark 492 This document extends the supported types in [I-D.blank-ietf-bimi] to 493 include Verified Mark Certificates but does not preclude the other 494 logo image types mentioned in there. In fact this proposal 495 explicitly calls for supporting other logos policies as the 496 requirements in this document may be too onerous. There are many 497 reasonable use cases as documented in VMC Guidelines document section 498 5 [20] that don't have registered trademarks, or need VMC validation. 499 Those other scenarios may use base images types as allowed in 500 [I-D.blank-ietf-bimi] or may be X.509 certificates perhaps following 501 their own validation profile but won't be described as Verified Mark 502 Certificates. Furthermore there may be non-branded scenarios but 503 validateable scenarios such as profile picture of an individual that 504 could be embedded in VM Certificates. Ultimately we want allow 505 senders and receivers flexibility in choosing which security, 506 authentication and authorization profile they wish to support and 507 use. 509 2.6. Logo Image Format 511 The format of the logo is governed by [RFC3709] and [RFC6170]. This 512 document proposes that the logo media be encapsulated and represented 513 as SVG vector graphics [21] so that the image representation supports 514 arbitrary visual rescaling. This has several advantages. First, the 515 logo image will always appear sharp no matter the display resolution. 516 Brand owners would likely prefer the brand logo to appear in the 517 client without image display artifacts like pixelation. Second, 518 having the ability to render the logo in arbitrary many sizes assists 519 in creating logo detection neural networks as it eases training those 520 neural networks. The general idea is for automatic creation of the 521 training dataset is creations of different appearances of the logo 522 with different sizes and locations. Such logo detection neural 523 networks assists in automated detection and trademark abuse 524 prevention both in the avatar and the message body. A third 525 advantage of standardizing on one scalable image format is that it 526 makes logo similarity comparison more deterministic. 528 One issue is the security of SVG. [RFC6170] specifies restrictions 529 on the SVG to secure it: 531 o Use SVG Tiny profile 533 o No script 535 o No external resource references 537 Only images that meet these requirements from RFC6170 are acceptable 538 for use with BIMI and must be validated by the CA/MVA. 540 2.7. Non-Display of Logo 542 Certificates that claim to Verified Mark Certificates that do not 543 follow these specifications must be ignored by the receivers and mail 544 clients, meaning that mail associated with these certificates would 545 have no brand symbol attached in the UI. Aside from the obvious 546 safety benefits, this provides an incentive for certificate issuers 547 and brand-owning domain registrants to follow these requirements. 548 Also, receivers are not bound to show the logo if they believe the 549 message is malicious or fraudulent such as when the receiver believes 550 the message is spammy or phishy. As noted above, when the mail 551 client believes that the user is outside the jurisdiction of the 552 trademark, then the logo should not be shown. If the Verified Mark 553 Certificate has expired, the mail client should not show the logo, 554 though still permitted to do so for UI continuity. If the Verified 555 Mark Certificate is revoked, the mail client must not show the logo. 557 2.8. BIMI Message Fetch 559 This normative description of this section is found in the Verified 560 Mark Certificate Usage document, and the content here is provided to 561 expand upon that description. 563 2.8.1. Mail Clients Support 565 A BIMI-aware IMAP client or proprietary client upon receiving a BIMI 566 verified message fetches the logo and displays the logo alongside the 567 message both in message view and threaded view. It should be placed 568 in a location distinct from the message body, in a way that prevents 569 message body content from spoofing the logo. It should be visually 570 distinct from non-BIMI verified messages as many mail clients 571 provides the means to display a profile image that might be used to 572 spoof a BIMI verified logo. Some ideas are to make the BIMI verified 573 logo larger, different shape or use animation. Also the UI should 574 support display of extra descriptive information in case the 575 recipient is unfamiliar with the logo. This could be a tooltip or 576 card panel. This information should include the curated trademark 577 name name if available, description of the sender, and the 578 jurisdiction of the logo from the Verified Mark Certificate subject. 579 As the ability of users to understand and recognize the logo [22] 580 across different mail user agents depends on consistency, 581 AuthIndicators working group should create a voluntary guideline and 582 encourage standard behavior across the email clients. This guideline 583 should updated periodically with input from all BIMI members 584 developing mail clients, taking into account current and future mail 585 client UIs. As noted earlier there are circumstances where the mail 586 client does not display the logo, and instead reverts to the non-BIMI 587 display behavior. 589 3. Security 591 3.1. Discussion 593 The proposal in this document attempts to create defense in depth. 594 If a malicious domain attempts to spoof a brand using the techniques 595 in this document, there are several preventative safeguards. In 596 order for the malicious domain to create and use a Verified Mark 597 Certificate, they must convince a CA/MVA to issue one that they can 598 publish. For arbitrary claimed logos/names the CA/MVA vetting 599 process should be able to detect the spoofed trademark i.e. lack of a 600 registered trademark, and prevent them from being issued. A 601 malicious domain could register a similar confusable trademark, but 602 some of these will be prevented by the trademark registration review 603 process. For those that are registered, these may pass CA/MVA 604 validation. If CT with preview becomes reality and these 605 certificates are pre-published in that previewable log as proposed 606 earlier, trademark monitors can detect spoofed trademark, block 607 issuance and if necessary file a court action against the owner of 608 the wrongly claimed trademark. When the certificate has already been 609 issued, the aggrieved owner can go to court. Upon court resolution 610 against the infringing confusable logo/name (or upon an injunction 611 issued prior to a final resolution), the CA/MVA can revoke the 612 Verified Mark Certificate. A malicious domain may try to forge email 613 with a valid RFC822.FROM domain aligned with a valid brand bearing 614 domain and BIMI header that uses that brand, but whose body contains 615 spam or phishing. This should fail SPF/DKIM message authentication 616 which prevents the brand logo from being shown. The logos provided 617 in the VMC can be used for anti-phishing models to help prevent 618 spoofing of legitimate mails. At the final step this proposal 619 provides visual branding imagery to help the recipient identify the 620 sender. 622 Visual security indicators have been a controversial topics since 623 "Why Johnny Can't Encrypt" [23] which noted that users have a hard 624 time understanding security concepts. As noted earlier, subsequent 625 research [24] indicated that web EV security indicators did not seem 626 to have an effect on stopping phishing as users seemingly tend to 627 ignore positive security indicators. More recent by Felt et al. [25] 628 provided a more nuanced view in that positive security indicators 629 have some effect on user decision making but was weaker than negative 630 indicators. Research is needed to see if that brand recognition can 631 have an effect albeit perhaps more weakly on security decisions. 632 Users already have a positive association with brands since brand 633 owners are incentivized to build brand equity by associating their 634 brand with a quality product or service. Brand owners then go about 635 educating consumers, allowing them to have strong brand recall and 636 discrimination [26]. This research is ongoing in the AuthIndicators 637 working group. Care must be taken though because the adversary will 638 try to spoof positive security indicators which will dupe the user 639 [27]. 641 3.2. X.509 Message Authentication Proposal 643 The proposed updates to BIMI in this document improve its security 644 profile, but there still are some security weaknesses for an 645 adversary to exploit. First, if SPF message authentication is used, 646 it is subject to MitM message modification. Second, both SPF/DKIM 647 message authentication are subject to DNS record attacks either 648 through MitM or DNS cache poisoning. Third, BIMI depends on three 649 separate mechanisms- DKIM or SPF/DMARC/BIMI to work right. A 650 relatively simple improvement to both reduce failure modes and attack 651 surface is to mandate the use of DKIM style full body message 652 authentication to resist message modification and use the private-key 653 associated with the Verified Mark Certificate to sign the DKIM 654 signature. Verified Mark Certificate aware receivers can use the 655 certificate public key to verify the message signature contained in 656 the DKIM header, and can skip the DKIM DNS record lookup. For 657 backwards compatibility this verification can still leverages DKIM 658 with its headers, and DNS record with the same public key as Verified 659 Mark Certificate, which allows non BIMI-aware email receivers to use 660 the DKIM for message authentication. While this still uses DNS to 661 locate information and even allows the use of the DKIM public key, 662 receivers aware of Verified Mark Certificates do not need to depend 663 on DNS to assert identity and instead uses cryptographic proof via 664 X.509 issuer-signed certificate that chains up to a CA root 665 certificate instead. Care must be taken with approach to prevent 666 downgrade attacks say between the approach in this section and that 667 of the rest of this document. Because of the additional complexity 668 and newness, this idea is relegated to future discussion. 670 4. Roadmap 672 This informational document describes the rationale for Verified Mark 673 Certificates. This presumes several normative, specification 674 documents: 1) Verified Mark Certificate profile and policy, 2) 675 Verified Mark Certificate handling by the receivers and 3) 676 Certificate Transparency for Verified Mark Certificates that includes 677 a preview process. The BIMI profile and policy document should be 678 reviewed and published through a policy directing body such as the 679 CA/Browser Forum or the AuthIndicators Working Group. The protocol 680 to fetch and handle Verified Mark Certificate by the receivers 681 document should be reviewed and published by the IETF. Lastly the 682 concept of CT logging with preview needs detailed review by the 683 community and may be submitted at an academic conference/workshop. 684 Assuming a satisfactory outcome, the final form of the preview work 685 too should be published through the IETF. 687 5. Conventions Used in This Document 689 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 690 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 691 document are to be interpreted as described in [RFC2119]. 693 6. References 695 6.1. Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, 699 DOI 10.17487/RFC2119, March 1997, 700 . 702 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 703 DOI 10.17487/RFC2397, August 1998, 704 . 706 [RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet 707 X.509 Public Key Infrastructure: Logotypes in X.509 708 Certificates", RFC 3709, DOI 10.17487/RFC3709, February 709 2004, . 711 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 712 Housley, R., and W. Polk, "Internet X.509 Public Key 713 Infrastructure Certificate and Certificate Revocation List 714 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 715 . 717 [RFC6170] Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol, 718 "Internet X.509 Public Key Infrastructure -- Certificate 719 Image", RFC 6170, DOI 10.17487/RFC6170, May 2011, 720 . 722 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 723 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 724 RFC 6376, DOI 10.17487/RFC6376, September 2011, 725 . 727 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 728 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 729 . 731 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 732 Authorizing Use of Domains in Email, Version 1", RFC 7208, 733 DOI 10.17487/RFC7208, April 2014, 734 . 736 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 737 Message Authentication, Reporting, and Conformance 738 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 739 . 741 6.2. Informative References 743 [I-D.blank-ietf-bimi] 744 Blank, S., Goldstein, P., Loder, T., and T. Zink, "Brand 745 Indicators for Message Identification (BIMI)", draft- 746 blank-ietf-bimi-00 (work in progress), February 2019. 748 [I-D.brotman-ietf-bimi-guidance] 749 Brotman, A. and T. Zink, "Receivers Guidance for 750 Implementing Branded Indicators for Message Identification 751 (BIMI)", draft-brotman-ietf-bimi-guidance-00 (work in 752 progress), February 2019. 754 6.3. URIs 756 [1] https://pdfs.semanticscholar.org/46d6/7fceac97a55fe9981b2d420f3b0 757 c357be00c.pdf 759 [2] https://research.google.com/pubs/archive/43962.pdf 761 [3] https://www.wired.com/2012/10/dkim-vulnerability-widespread/ 763 [4] https://www.wired.com/2014/03/quantum/ 765 [5] https://blog.apnic.net/2017/12/06/dnssec-deployment-remains-low/ 767 [6] https://docs.google.com/document/ 768 d/1OzL9FqexZpZJQuoqAK2E3sXjOwEcLNCvXW7e88Olt2I/edit?usp=sharing 770 [7] https://stripe.ian.sh/ 772 [8] https://typewritten.net/write/ev-phishing/ 774 [9] http://whatculture.com/offbeat/10-massive-companies-unbelievably- 775 similar-logos 777 [10] http://www.usablesecurity.org/papers/jackson.pdf 779 [11] https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf 781 [12] https://docs.google.com/document/ 782 d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing 784 [13] https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf 786 [14] https://docs.google.com/document/ 787 d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing 789 [15] https://www.uspto.gov/trademarks-application-process/faqs- 790 personal-information-trademark-records 792 [16] https://euipo.europa.eu/tunnel- 793 web/secure/webdav/guest/document_library/contentPdfs/ 794 data_protection/EUIPOs_explanatory_note_en.pdf 796 [17] https://www.markmonitor.com/ 798 [18] https://www.brandwatch.com/blog/top-image-recognition-tools 800 [19] https://secureyourtrademark.com/blog/trademark-101-monitoring- 801 strategies-can-implement/ 803 [20] https://docs.google.com/document/ 804 d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/ 805 edit#bookmark=id.r701mosrrfx3 807 [21] https://www.w3.org/TR/SVG11/ 809 [22] https://static.googleusercontent.com/media/research.google.com/ 810 en//pubs/archive/45366.pdf 812 [23] https://people.eecs.berkeley.edu/~tygar/papers/ 813 Why_Johnny_Cant_Encrypt/OReilly.pdf. 815 [24] http://www.usablesecurity.org/papers/jackson.pdf 817 [25] https://www.usenix.org/system/files/conference/soups2016/ 818 soups2016-paper-porter-felt.pdf 820 [26] https://faculty.fuqua.duke.edu/~moorman/Marketing-Strategy- 821 Seminar-2015/Session%203/Keller.pdf 823 [27] http://people.ischool.berkeley.edu/~tygar/papers/Phishing/ 824 why_phishing_works.pdf 826 Authors' Addresses 828 Weihaw Chuang (editor) 829 Google, Inc. 831 Email: weihaw@google.com 833 Thede Loder (editor) 834 Skye Logicworks 836 Email: thede@skyelogicworks.com