Internet DRAFT - draft-chuang-ietf-bimi-security-perspectives

draft-chuang-ietf-bimi-security-perspectives







Application Area Working Group                            W. Chuang, Ed.
Internet-Draft                                              Google, Inc.
Intended status: Informational                             T. Loder, Ed.
Expires: September 12, 2019                              Skye Logicworks
                                                          March 11, 2019


      Verified Mark Certificates Proposal: A Security Perspective
            draft-chuang-ietf-bimi-security-perspectives-00

Abstract

   This document motivates the need for embedding logotypes in X.509
   certificates along with the certificate validation process from a
   security perspective.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Chuang & Loder         Expires September 12, 2019               [Page 1]

Internet-Draft          VMC Security Perspective              March 2019


Table of Contents

   1.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Critique of the BIMI Proposals  . . . . . . . . . . . . .   3
       1.1.1.  BIMI Draft  . . . . . . . . . . . . . . . . . . . . .   3
       1.1.2.  BIMI Guidance (So far) About Certificates . . . . . .   5
   2.  Verified Mark Certificate . . . . . . . . . . . . . . . . . .   7
     2.1.  Certificate Association With Logo . . . . . . . . . . . .   7
     2.2.  Verified Identity of Sender . . . . . . . . . . . . . . .   8
     2.3.  Root Program  . . . . . . . . . . . . . . . . . . . . . .   8
     2.4.  Certificate Transparency  . . . . . . . . . . . . . . . .   9
     2.5.  Registered Trademark  . . . . . . . . . . . . . . . . . .  10
       2.5.1.  Coexistence with non-Registered Trademark . . . . . .  11
     2.6.  Logo Image Format . . . . . . . . . . . . . . . . . . . .  11
     2.7.  Non-Display of Logo . . . . . . . . . . . . . . . . . . .  12
     2.8.  BIMI Message Fetch  . . . . . . . . . . . . . . . . . . .  12
       2.8.1.  Mail Clients Support  . . . . . . . . . . . . . . . .  12
   3.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .  13
     3.2.  X.509 Message Authentication Proposal . . . . . . . . . .  14
   4.  Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.  Conventions Used in This Document . . . . . . . . . . . . . .  15
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  16
     6.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Objectives

   Many Mail User Agents and mail systems provide logo imagery as
   avatars as part of the user interface chrome.  For branded email, the
   agents and systems use different, proprietary methods for
   provisioning the avatar which causes consistency problems.  Instead
   there should a common, internet scale, secure method to fetch the
   sender's brand logo indicators during message delivery which this
   document along with others documents by the AuthIndicators Working
   Group (aka BIMI Working Group) propose.

   Given the potential for impersonation abuse if not safeguarded, the
   proposal incorporates defense in depth as it assumes an adversarial
   security model and that parties will attempt to exploit sender/
   subscribers for their own criminal benefit.  Due to this risk of
   identity spoofing, a sender's identity is verified by a Certificate
   Authority (CA) that acts as a Mark Verification Authority (MVA) that
   then issues X.509 certificate with this evidence as a Verified Mark
   Certificate (VMC).  One risk is that the MVA may fail to distinguish
   a spoofed identity during their verification either by oversight or



Chuang & Loder         Expires September 12, 2019               [Page 2]

Internet-Draft          VMC Security Perspective              March 2019


   intentionally.  To enable detection, issued certificates are publicly
   disclosed through permanent untamperable logs that can be verified by
   receivers, trademark monitors, the trademark holders themselves, and
   other interested parties.  Because of this, email receivers will have
   greater confidence that the sender's logo is what the sender says
   they are.

   The logo may be presented to the recipient if the email is at a
   minimum authenticated via SPF [RFC7208], or DKIM [RFC6376], and
   passes the DMARC [RFC7489] policy check.  Because this proposal uses
   domain authentication and DMARC in order for the logo to be shown, it
   incentivizes the use of these domain authentication and authorization
   methods.  These methods are important because they provide a
   consistent means of protecting against an sender domain spoofing.
   However the FTC Office of Technology Research and Investigation in
   2017 found that 66% of business mail domains did not use DMARC.  Logo
   carrying mail must also pass other receiver requirements such as not
   phish and not spam per their own policies.  Domain-based
   authentication methods SPF, and DKIM, enables the email receivers'
   automated anti-abuse systems to tie together emails sent by the same
   sender to generate accurate per domain reputations that allow them to
   filter abusive emails.  The Verified Mark Certificate contains
   curated sender's metadata, that provides additional signals for anti-
   phishing.

   This document builds on the more generalized brand logo association
   drafts that is specified in [I-D.blank-ietf-bimi] and
   [I-D.brotman-ietf-bimi-guidance].  This document is meant to motivate
   the purpose for Verified Mark Certificates, and is purely
   informative.  The Roadmap (Section 4) section calls out where
   normative documents are needed.

1.1.  Critique of the BIMI Proposals

1.1.1.  BIMI Draft

   The [I-D.blank-ietf-bimi], dated February 6, 2019 aka the "Assertion
   Record" specification, states as its objectives the following goals:

   o  No dependency on new Internet protocols or services for indicator
      registration or revocation

   o  Incremental deployment

   o  Policies solely published in BIMI DNS (TXT) record

   o  Delegation by logo owners to third party logo providers




Chuang & Loder         Expires September 12, 2019               [Page 3]

Internet-Draft          VMC Security Perspective              March 2019


   o  Scalability of brand associations across internet scale of domains

   o  Uniformity of brands displayed

   (BIMI stands for Brand Indicators for Message Identification) The
   Assertion Record draft uses SPF/DKIM/DMARC for message verification.
   It defines optional header metadata and defaults to determine from
   where to fetch the logo policy and locator from BIMI DNS TXT records.
   From these, the receiver can generate a URL to fetch the logo.  It
   succeeds with the above goals, however it admits an important
   limitation in that it does not specify "verification and reputation"
   mechanisms and depends on them to prevent abuse.  This document
   describes solutions for those limitations.

1.1.1.1.  BIMI Draft Threat Modeling

   Because some of the uses of branded email are high-value
   transactional and business emails, there is the possibility the
   protocol might be abused.  Consequently the following is a threat
   model to identify security weaknesses in the above protocol.
   Malicious senders may spoof trusted identities for phishing or spam
   by copying brand identities or by creating a similar but confusable
   logo, served from their domain with their own domain authentication.
   A adversary could:

   o  game the receiver's reputation system by using automated networks
      [1] to send good email traffic and then launch an attack.

   o  related concern, is the problem of low traffic senders that
      receivers will have difficulty determining reputation.

   An explicit definition of trustworthiness may be helpful establishing
   a reputation in these circumstances.

   Another attack is to exploit the vulnerability of the email system by
   injecting emails crafted by the adversary that use the good sender's
   identity.  While BIMI uses message authentication through SPF/DKIM/
   DMARC that is meant to prevent this type of spoofing, the adversary
   could exploit domains with weak authentication via:

   o  overly broad SPF [2] policies acceptance policies

   o  weak DKIM keys [3]

   Fortunately good senders can easily fix this.  The adversary could
   exploit weaknesses in DNS integrity as message authentication depends
   on the integrity of the SPF/DKIM/DMARC records which may be attacked
   through DNS cache poisoning or man-in-the-middle (MitM).  While such



Chuang & Loder         Expires September 12, 2019               [Page 4]

Internet-Draft          VMC Security Perspective              March 2019


   attacks seem far fetched, the Snowden disclosures [4] show that
   nation-state adversaries have been able to mount such attacks.
   Unfortunately deployment of DNS protection through DNSSEC seems to be
   stalled [5].

1.1.2.  BIMI Guidance (So far) About Certificates

   The [I-D.brotman-ietf-bimi-guidance] dated on 6 Feb 6 2019 aka
   "Receivers Guidance" extends and provides best practices for the
   Assertion Records draft.  It notes the use of Verified Mark
   Certificates which is new certificate issued by Mark Verifying
   Authorities (MVA) to resist the spoofing attacks though with limited
   details on validation and usage.  The Receivers Guidance document
   states receivers should work with multiple MVAs to allow the
   successful untrust of any one malicious MVA.  It also calls for
   receivers to partner with Dispute Resolution Agencies to handle
   trademark conflicts as well as acknowledges the courts primacy for
   conflict resolution.  It has other guidance: it notes that receivers
   MTA may fetch and store the logo for the MUA or it may have the MUA
   fetch it itself.  It also provides deployment guidance on domain
   authentication and DMARC.

   The Receiver Guidance document references an AuthIndicators Working
   Group document "Verified Mark Certificates Usage (for review)" [6]
   dated 23 October 2018 for details about Verified Mark Certificates.
   That document is a specification on the handling of Verified Mark
   Certificates by the receiver MTA and recipient MUA.  It defines the
   VMC validation and fetch process designed to protect the privacy for
   the recipient from the sender- VMC fetch occurs at delivery time, and
   cached by the MTA for use by the MUA, thus view time usage of the VMC
   is hidden from the sender.  Similarly Certificate Revocation Lists
   (CRLs) are specified to allow for offline revocation checking of the
   certificate.  (There is the related scenario of keeping private the
   use of the VM Certificate content by the recipient from the receiver.
   This hasn't been specified in any of the documents, but a likely
   solution would be embed the logo as a new header for use by the MUA)

   Notably those two documents avoid detailed discussion on the use of
   Verified Mark Certificates for which this document tries to fill in.
   Moreover, there are potential operational risks with using curated
   information provided by X.509 certificates that this document
   discusses next.

1.1.2.1.  Problems with Certificates

   Experience using identity carrying certificates have identified
   several important issues.  An adversary attempting to spoof an




Chuang & Loder         Expires September 12, 2019               [Page 5]

Internet-Draft          VMC Security Perspective              March 2019


   identity might try to exploit weaknesses in certificate issuance
   validation.

   o  Lax or intentionally malicious validation by CA/MVA may allow an
      adversary to impersonate with a copied or look alike identity.

   o  Ambiguities in the registered identity that the CA/MVA checks
      against may allow an adversary to obtain an "legitimate" identity
      for spoofing.  Note that arguably the CA/MVA validation is
      considered successful here.

      *  Carroll [7] demonstrated in 2017 that ambiguities caused by
         different jurisdictions allowed him to obtain a web EV
         certificate for "Stripe, Inc." in Kentucky that could have
         allowed him to spoof the better known "Stripe, Inc" in
         Delaware.  While browsers displays differences in country
         jurisdiction, it does not show state level information, and
         even if it did, it is doubtful users would notice.  The analog
         for logos is that an adversary that desires spoofing logos in
         one jurisdiction would register similar or identical logos in
         another.

      *  Burton [8] similarly demonstrated that he could obtain a web EV
         certificate for a misleading company name with a positive
         sounding security message e.g.  "Identity Verified".  The
         analog logo attack might be that the adversary registers a
         checkmark or padlock logo.

      *  "Cousin marks" are similar but legitimate logos add another
         dimension of confusability as illustrated by this list [9].
         This confusability of this list seems to be caused by the
         trademark registration agency allowing similar logos when the
         company's line of business don't overlap.

   With these spoofing attacks, one issue has been understanding the
   scope of the attack i.e. given one bad certificate, if there are
   other ones.  Lack of global visibility in what has been issued has
   historically made this problematic.

   The largest deployed set of these identity carrying certificates has
   been web Extended Validation (EV) where the subscribers legal
   identity gets additional validation.  Web sites uses these EV
   certificates get additional chrome e.g. historically a green "bar"
   containing the company name and padlock indicator.  However
   operational experience has indicated problems with this approach:

   o  Jackson et al. [10] found that using the web EV green padlock UI
      as a positive security indicator was not effective in helping



Chuang & Loder         Expires September 12, 2019               [Page 6]

Internet-Draft          VMC Security Perspective              March 2019


      users distinguish good websites from phishing as users did not
      notice the indicators.

   o  Company names sometime are not familiar to users.  For example
      Google's parent company name is "Alphabet Inc" which likely isn't
      as familiar as "Google".

2.  Verified Mark Certificate

   This section specifies issuing a BIMI-specific X.509 certificate that
   binds logos and other information to domains and to a legal entity.
   CA/MVAs validate the binding and the X.509 CA based PKI proves to all
   parties that this validation was done.  These certificates are called
   Verified Mark Certificates (VMC or VM Certificates aka Mark Verified
   Certificates or MVC in some of our other documents).  This document
   primarily works with the use of registered trademarks as it provides
   a useful legal framework to establish VMC upon, however the
   AuthIndicators working group is evaluating how to expand that to
   include other non-registered identities.

2.1.  Certificate Association With Logo

   Existing work provides specification for brand logos in X.509 PKIX
   certificates as specified in [RFC3709] and [RFC6170].  The logo
   images can be embedded within the X.509 certificate as a subject
   extension [RFC3709] using a DATA URL mentioned in [RFC6170] and
   specified in [RFC2397].  The certificate subject identifier describes
   a legal owner of the brand that can be used for verification, and a
   DNS domain that matches the sender's email address domain.  The
   validation of these identities can follow the procedures in CABF EV
   baseline 1.6 [11] with additional guidelines specific for BIMI as
   described in these Guidelines for Issuance of Verified Mark
   Certificates v0.97 [12].

   The Verified Mark Certificate must chain-up to a well known public
   trust anchor i.e. a well known Certificate Authority certificate
   issuer.  This provides a cryptographic means to prove that a domain
   owns a brand to the relying party as long as they can trust the
   transitive issuing policy.  If the logo bearing certificate is a CA
   certificate, then it must be name constrained to the owning domain or
   subdomain.  This prevents the brand from being wrongly associated
   with some non-owning domain for some child entity certificate issued
   from the CA certificate.  [RFC3709] allows the specification of only
   one logo per certificate.  The issuer may need to issue multiple
   certificates that bear different logos for the brand.  The
   appropriate logo is optionally selected by the BIMI email header as
   mentioned in [I-D.blank-ietf-bimi] or defaults to the default for the
   organizational domain name.



Chuang & Loder         Expires September 12, 2019               [Page 7]

Internet-Draft          VMC Security Perspective              March 2019


2.2.  Verified Identity of Sender

   The Verified Mark Certificate issuance process builds upon the web
   Extended Validation (EV) [13] certificates issuance guidelines, with
   appropriate extensions as described Guidelines for Issuance of
   Verified Mark Certificates v0.97 [14].  In particular the brand
   ownership must undergo rigorous validation by the issuing CA back to
   that legal entity, including explicit face-to-face identity
   validation of the applicant.  CAs already have experience validating
   internet domain ownership back to legal entities for the web EV
   program, and it would be reasonably feasible for them to examine
   brand IP as well since these may be registered in government
   trademark registries i.e. the logos must match a registered trademark
   as described later.  In addition brand names may also be specified
   and found in those registries, as often they are more easily
   recognized than the owning company's name.  CAs performing these
   additional vetting steps would act as the Mark Verifying Authorities
   (MVA) mentioned earlier.  Further, the requesting party for the
   certificates must meet certain minimum identification and formation
   requirement e.g. be an incorporated company, government body or
   registered non-profit known in the public record.  The requesting
   party's legal address is disclosed in the certificate for
   identification by the recipient and other interested parties
   following the practices of the trademark jurisdiction.  For example
   here's the link to USPTO [15] FAQ, and the link for EU [16] (on page
   3).  This also in some hopefully limited circumstance may help an
   aggrieved party serve legal notice.

   In summary the VMC Guidelines validation process proves that:

   o  Legal entity is legitimate

   o  Domain names are controlled by the organization

   o  Person requesting the certificate

      *  Duly and currently authorized to do so by the organization

      *  Who they say they are

   o  Legal entity has the rights to display the trademark logo (design
      mark) and optionally name (text mark)

2.3.  Root Program

   BIMI-aware email receivers and/or mail clients should maintain their
   own trusted BIMI CA/MVA root certificate store programs, or otherwise
   rely on a program by another receiver.  Such programs would manage a



Chuang & Loder         Expires September 12, 2019               [Page 8]

Internet-Draft          VMC Security Perspective              March 2019


   fixed set of BIMI root certificates managed much like browser root
   certificates.  Most importantly these BIMI root certificate set
   owners must create a security program to monitor the performance of
   CA/MVA to adhere to their CPS much like the browser programs.  A
   fixed root certificate set creates certainty for the sender and
   recipients and mitigates some BIMI header attacks.  Certain receivers
   could publish their root CAs, which would make it possible for
   intended certificate subscribers to identify supported CAs.  It also
   moves much of the security work to the email receivers from the
   sender, which are better positioned to do this work due to their
   security staffing and association with browser security teams (with
   their expertise in X.509 PKI security).

2.4.  Certificate Transparency

   We also propose that these certificates be published in Certificate
   Transparency logs [RFC6962] analogous to those operated for web EV
   certificates.  Certificate Transparency (CT) logs are append only
   which provides protection against equivocation i.e. manipulating the
   logs to show different views to different requesters.  A VM
   Certificate proves that it is published in a CT log by including a
   SCT extension generated when logged.  All relying parties must check
   for the presence of the valid SCT, and reject the certificate if it
   is not present.  Mandatory publishing provides global transparency
   that makes it easier to detect other similar impersonation attacks or
   mis-issuance.  Global transparency provides certainty once a problem
   has been detected that it can be fully remedied and contained.

   While RFC3709 may allow an external logo with a secure hash which may
   be convenient, an adversary may simply not supply potentially
   incriminating logo during an investigation.  Instead we propose
   embedding the logos in the Verified Mark Certificate.  With this the
   VMC CT log also provides a catalog of curated logos and their
   ownership in a machine readable form that may then be used by anti-
   abuse systems for use as reference identities.

   This document proposes that the major mail systems using VMC along
   with VMC issuing CAs should run their own publicly visible CT logs.
   While logging may be done collaboratively, there must always be
   enough diversity so that multiple logs are available under separate
   ownership to prevent conflict of interest.  Mail systems can elect to
   require logging to their CT log in order to show the logos.

   While some companies (e.g.  Google) already actively monitors the CT
   logs for misissuance, many companies don't that should monitor CT
   logs.  This document encourages the development of log monitoring
   services in particular visual logo monitoring to protect brands from
   spoofing.  For example, it is conceivable that a CA may be interested



Chuang & Loder         Expires September 12, 2019               [Page 9]

Internet-Draft          VMC Security Perspective              March 2019


   in providing issuing and monitoring service for brands as part of
   their commercial offering.  Along those lines there are companies
   specialized in mark monitoring e.g.  MarkMonitor [17] that might be
   interested.  Automated visual recognition of logos is a capability
   commercially available e.g. top 8 list [18].

   Beyond that we also propose research into pre-publication of the
   certificate in the CT logs before issuance that allows trademark
   monitors to detect and block issuance if necessary.  These monitors
   would follow the log to look for trademark infringement, improperly
   created certificates, and other abuses, and can file complaints to
   the log.  If the conflict is not initially resolved between the
   parties on he log, then the trademark owners have access to the
   courts.  Assuming the research into CT with preview, which is being
   investigated by the AuthIndicators working group, proves its
   feasibility, this can potentially be followed up with standards work.

2.5.  Registered Trademark

   Using registered trademark helps clarifies ownership of the logo, and
   raises the difficulty of succeeding at impersonation.  The
   registration process in many jurisdictions requires that the
   trademark be distinctive and non-confusable with another.  To enforce
   this, many jurisdictions use a public review period and brands
   already employ brand monitors [19] to protect the trademarks.  As
   part of this review, many jurisdictions have tests for objectionable
   or deceptive marks e.g.  "Identity Verified".  It also provides a
   central authority that documents existing trademarks where an issuing
   CA/MVA can match the submitted embedded logo to the documented
   trademark.  If there is a dispute between non-fraudulent parties,
   registration provides access to the courts, and consequently
   trademark conflict resolution becomes a process of following the
   court process.  The certificate identifies the trademark owner in
   case it is necessary to start those legal proceedings.

   One issue is jurisdiction as trademarks laws and practices differ.
   This proposes that the smallest scope should be nation level where
   trademark law is well established.  Trademarks may also be registered
   internationally (across 90+ countries) via the Madrid union and due
   to the universal first world coverage of the Madrid union and largely
   the rest of the world, such a trademark can be considered global
   jurisdiction.  Similarly well known regional, multi-country
   jurisdictions e.g EU should be distinguishable as well.  The country
   code information can be specified in the certificate trademark
   jurisdiction field.  Display of the brand logo/name information
   should follow where the information is valid, and this can be done by
   displaying the logo only when the client is within the jurisdiction
   to the best of the client's ability e.g.  GPS on mobile devices, and



Chuang & Loder         Expires September 12, 2019              [Page 10]

Internet-Draft          VMC Security Perspective              March 2019


   IP geolocation on desktop computers.  A second closely related issue
   is the strength of a particular jurisdiction trademark review and
   legal system to prevent fraudulent trademarks.  A concern is that
   they may differ in their ability to prevent spoofing.  The
   AuthIndicators Working Group in conjunction with the CA/MVA and mail
   systems will review and publish findings on the strength of
   particular jurisdictions.  International cross border registration or
   multiple jurisdiction registration maybe helpful when some countries
   have better trademark databases than others and should be encouraged.

2.5.1.  Coexistence with non-Registered Trademark

   This document extends the supported types in [I-D.blank-ietf-bimi] to
   include Verified Mark Certificates but does not preclude the other
   logo image types mentioned in there.  In fact this proposal
   explicitly calls for supporting other logos policies as the
   requirements in this document may be too onerous.  There are many
   reasonable use cases as documented in VMC Guidelines document section
   5 [20] that don't have registered trademarks, or need VMC validation.
   Those other scenarios may use base images types as allowed in
   [I-D.blank-ietf-bimi] or may be X.509 certificates perhaps following
   their own validation profile but won't be described as Verified Mark
   Certificates.  Furthermore there may be non-branded scenarios but
   validateable scenarios such as profile picture of an individual that
   could be embedded in VM Certificates.  Ultimately we want allow
   senders and receivers flexibility in choosing which security,
   authentication and authorization profile they wish to support and
   use.

2.6.  Logo Image Format

   The format of the logo is governed by [RFC3709] and [RFC6170].  This
   document proposes that the logo media be encapsulated and represented
   as SVG vector graphics [21] so that the image representation supports
   arbitrary visual rescaling.  This has several advantages.  First, the
   logo image will always appear sharp no matter the display resolution.
   Brand owners would likely prefer the brand logo to appear in the
   client without image display artifacts like pixelation.  Second,
   having the ability to render the logo in arbitrary many sizes assists
   in creating logo detection neural networks as it eases training those
   neural networks.  The general idea is for automatic creation of the
   training dataset is creations of different appearances of the logo
   with different sizes and locations.  Such logo detection neural
   networks assists in automated detection and trademark abuse
   prevention both in the avatar and the message body.  A third
   advantage of standardizing on one scalable image format is that it
   makes logo similarity comparison more deterministic.




Chuang & Loder         Expires September 12, 2019              [Page 11]

Internet-Draft          VMC Security Perspective              March 2019


   One issue is the security of SVG.  [RFC6170] specifies restrictions
   on the SVG to secure it:

   o  Use SVG Tiny profile

   o  No script

   o  No external resource references

   Only images that meet these requirements from RFC6170 are acceptable
   for use with BIMI and must be validated by the CA/MVA.

2.7.  Non-Display of Logo

   Certificates that claim to Verified Mark Certificates that do not
   follow these specifications must be ignored by the receivers and mail
   clients, meaning that mail associated with these certificates would
   have no brand symbol attached in the UI.  Aside from the obvious
   safety benefits, this provides an incentive for certificate issuers
   and brand-owning domain registrants to follow these requirements.
   Also, receivers are not bound to show the logo if they believe the
   message is malicious or fraudulent such as when the receiver believes
   the message is spammy or phishy.  As noted above, when the mail
   client believes that the user is outside the jurisdiction of the
   trademark, then the logo should not be shown.  If the Verified Mark
   Certificate has expired, the mail client should not show the logo,
   though still permitted to do so for UI continuity.  If the Verified
   Mark Certificate is revoked, the mail client must not show the logo.

2.8.  BIMI Message Fetch

   This normative description of this section is found in the Verified
   Mark Certificate Usage document, and the content here is provided to
   expand upon that description.

2.8.1.  Mail Clients Support

   A BIMI-aware IMAP client or proprietary client upon receiving a BIMI
   verified message fetches the logo and displays the logo alongside the
   message both in message view and threaded view.  It should be placed
   in a location distinct from the message body, in a way that prevents
   message body content from spoofing the logo.  It should be visually
   distinct from non-BIMI verified messages as many mail clients
   provides the means to display a profile image that might be used to
   spoof a BIMI verified logo.  Some ideas are to make the BIMI verified
   logo larger, different shape or use animation.  Also the UI should
   support display of extra descriptive information in case the
   recipient is unfamiliar with the logo.  This could be a tooltip or



Chuang & Loder         Expires September 12, 2019              [Page 12]

Internet-Draft          VMC Security Perspective              March 2019


   card panel.  This information should include the curated trademark
   name name if available, description of the sender, and the
   jurisdiction of the logo from the Verified Mark Certificate subject.
   As the ability of users to understand and recognize the logo [22]
   across different mail user agents depends on consistency,
   AuthIndicators working group should create a voluntary guideline and
   encourage standard behavior across the email clients.  This guideline
   should updated periodically with input from all BIMI members
   developing mail clients, taking into account current and future mail
   client UIs.  As noted earlier there are circumstances where the mail
   client does not display the logo, and instead reverts to the non-BIMI
   display behavior.

3.  Security

3.1.  Discussion

   The proposal in this document attempts to create defense in depth.
   If a malicious domain attempts to spoof a brand using the techniques
   in this document, there are several preventative safeguards.  In
   order for the malicious domain to create and use a Verified Mark
   Certificate, they must convince a CA/MVA to issue one that they can
   publish.  For arbitrary claimed logos/names the CA/MVA vetting
   process should be able to detect the spoofed trademark i.e. lack of a
   registered trademark, and prevent them from being issued.  A
   malicious domain could register a similar confusable trademark, but
   some of these will be prevented by the trademark registration review
   process.  For those that are registered, these may pass CA/MVA
   validation.  If CT with preview becomes reality and these
   certificates are pre-published in that previewable log as proposed
   earlier, trademark monitors can detect spoofed trademark, block
   issuance and if necessary file a court action against the owner of
   the wrongly claimed trademark.  When the certificate has already been
   issued, the aggrieved owner can go to court.  Upon court resolution
   against the infringing confusable logo/name (or upon an injunction
   issued prior to a final resolution), the CA/MVA can revoke the
   Verified Mark Certificate.  A malicious domain may try to forge email
   with a valid RFC822.FROM domain aligned with a valid brand bearing
   domain and BIMI header that uses that brand, but whose body contains
   spam or phishing.  This should fail SPF/DKIM message authentication
   which prevents the brand logo from being shown.  The logos provided
   in the VMC can be used for anti-phishing models to help prevent
   spoofing of legitimate mails.  At the final step this proposal
   provides visual branding imagery to help the recipient identify the
   sender.

   Visual security indicators have been a controversial topics since
   "Why Johnny Can't Encrypt" [23] which noted that users have a hard



Chuang & Loder         Expires September 12, 2019              [Page 13]

Internet-Draft          VMC Security Perspective              March 2019


   time understanding security concepts.  As noted earlier, subsequent
   research [24] indicated that web EV security indicators did not seem
   to have an effect on stopping phishing as users seemingly tend to
   ignore positive security indicators.  More recent by Felt et al. [25]
   provided a more nuanced view in that positive security indicators
   have some effect on user decision making but was weaker than negative
   indicators.  Research is needed to see if that brand recognition can
   have an effect albeit perhaps more weakly on security decisions.
   Users already have a positive association with brands since brand
   owners are incentivized to build brand equity by associating their
   brand with a quality product or service.  Brand owners then go about
   educating consumers, allowing them to have strong brand recall and
   discrimination [26].  This research is ongoing in the AuthIndicators
   working group.  Care must be taken though because the adversary will
   try to spoof positive security indicators which will dupe the user
   [27].

3.2.  X.509 Message Authentication Proposal

   The proposed updates to BIMI in this document improve its security
   profile, but there still are some security weaknesses for an
   adversary to exploit.  First, if SPF message authentication is used,
   it is subject to MitM message modification.  Second, both SPF/DKIM
   message authentication are subject to DNS record attacks either
   through MitM or DNS cache poisoning.  Third, BIMI depends on three
   separate mechanisms- DKIM or SPF/DMARC/BIMI to work right.  A
   relatively simple improvement to both reduce failure modes and attack
   surface is to mandate the use of DKIM style full body message
   authentication to resist message modification and use the private-key
   associated with the Verified Mark Certificate to sign the DKIM
   signature.  Verified Mark Certificate aware receivers can use the
   certificate public key to verify the message signature contained in
   the DKIM header, and can skip the DKIM DNS record lookup.  For
   backwards compatibility this verification can still leverages DKIM
   with its headers, and DNS record with the same public key as Verified
   Mark Certificate, which allows non BIMI-aware email receivers to use
   the DKIM for message authentication.  While this still uses DNS to
   locate information and even allows the use of the DKIM public key,
   receivers aware of Verified Mark Certificates do not need to depend
   on DNS to assert identity and instead uses cryptographic proof via
   X.509 issuer-signed certificate that chains up to a CA root
   certificate instead.  Care must be taken with approach to prevent
   downgrade attacks say between the approach in this section and that
   of the rest of this document.  Because of the additional complexity
   and newness, this idea is relegated to future discussion.






Chuang & Loder         Expires September 12, 2019              [Page 14]

Internet-Draft          VMC Security Perspective              March 2019


4.  Roadmap

   This informational document describes the rationale for Verified Mark
   Certificates.  This presumes several normative, specification
   documents: 1) Verified Mark Certificate profile and policy, 2)
   Verified Mark Certificate handling by the receivers and 3)
   Certificate Transparency for Verified Mark Certificates that includes
   a preview process.  The BIMI profile and policy document should be
   reviewed and published through a policy directing body such as the
   CA/Browser Forum or the AuthIndicators Working Group.  The protocol
   to fetch and handle Verified Mark Certificate by the receivers
   document should be reviewed and published by the IETF.  Lastly the
   concept of CT logging with preview needs detailed review by the
   community and may be submitted at an academic conference/workshop.
   Assuming a satisfactory outcome, the final form of the preview work
   too should be published through the IETF.

5.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
              DOI 10.17487/RFC2397, August 1998,
              <https://www.rfc-editor.org/info/rfc2397>.

   [RFC3709]  Santesson, S., Housley, R., and T. Freeman, "Internet
              X.509 Public Key Infrastructure: Logotypes in X.509
              Certificates", RFC 3709, DOI 10.17487/RFC3709, February
              2004, <https://www.rfc-editor.org/info/rfc3709>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.





Chuang & Loder         Expires September 12, 2019              [Page 15]

Internet-Draft          VMC Security Perspective              March 2019


   [RFC6170]  Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol,
              "Internet X.509 Public Key Infrastructure -- Certificate
              Image", RFC 6170, DOI 10.17487/RFC6170, May 2011,
              <https://www.rfc-editor.org/info/rfc6170>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

6.2.  Informative References

   [I-D.blank-ietf-bimi]
              Blank, S., Goldstein, P., Loder, T., and T. Zink, "Brand
              Indicators for Message Identification (BIMI)", draft-
              blank-ietf-bimi-00 (work in progress), February 2019.

   [I-D.brotman-ietf-bimi-guidance]
              Brotman, A. and T. Zink, "Receivers Guidance for
              Implementing Branded Indicators for Message Identification
              (BIMI)", draft-brotman-ietf-bimi-guidance-00 (work in
              progress), February 2019.

6.3.  URIs

   [1] https://pdfs.semanticscholar.org/46d6/7fceac97a55fe9981b2d420f3b0
       c357be00c.pdf

   [2] https://research.google.com/pubs/archive/43962.pdf

   [3] https://www.wired.com/2012/10/dkim-vulnerability-widespread/

   [4] https://www.wired.com/2014/03/quantum/




Chuang & Loder         Expires September 12, 2019              [Page 16]

Internet-Draft          VMC Security Perspective              March 2019


   [5] https://blog.apnic.net/2017/12/06/dnssec-deployment-remains-low/

   [6] https://docs.google.com/document/
       d/1OzL9FqexZpZJQuoqAK2E3sXjOwEcLNCvXW7e88Olt2I/edit?usp=sharing

   [7] https://stripe.ian.sh/

   [8] https://typewritten.net/write/ev-phishing/

   [9] http://whatculture.com/offbeat/10-massive-companies-unbelievably-
       similar-logos

   [10] http://www.usablesecurity.org/papers/jackson.pdf

   [11] https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf

   [12] https://docs.google.com/document/
        d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing

   [13] https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf

   [14] https://docs.google.com/document/
        d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing

   [15] https://www.uspto.gov/trademarks-application-process/faqs-
        personal-information-trademark-records

   [16] https://euipo.europa.eu/tunnel-
        web/secure/webdav/guest/document_library/contentPdfs/
        data_protection/EUIPOs_explanatory_note_en.pdf

   [17] https://www.markmonitor.com/

   [18] https://www.brandwatch.com/blog/top-image-recognition-tools

   [19] https://secureyourtrademark.com/blog/trademark-101-monitoring-
        strategies-can-implement/

   [20] https://docs.google.com/document/
        d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/
        edit#bookmark=id.r701mosrrfx3

   [21] https://www.w3.org/TR/SVG11/

   [22] https://static.googleusercontent.com/media/research.google.com/
        en//pubs/archive/45366.pdf





Chuang & Loder         Expires September 12, 2019              [Page 17]

Internet-Draft          VMC Security Perspective              March 2019


   [23] https://people.eecs.berkeley.edu/~tygar/papers/
        Why_Johnny_Cant_Encrypt/OReilly.pdf.

   [24] http://www.usablesecurity.org/papers/jackson.pdf

   [25] https://www.usenix.org/system/files/conference/soups2016/
        soups2016-paper-porter-felt.pdf

   [26] https://faculty.fuqua.duke.edu/~moorman/Marketing-Strategy-
        Seminar-2015/Session%203/Keller.pdf

   [27] http://people.ischool.berkeley.edu/~tygar/papers/Phishing/
        why_phishing_works.pdf

Authors' Addresses

   Weihaw Chuang (editor)
   Google, Inc.

   Email: weihaw@google.com


   Thede Loder (editor)
   Skye Logicworks

   Email: thede@skyelogicworks.com

























Chuang & Loder         Expires September 12, 2019              [Page 18]