| 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
This document motivates the need for embedding logotypes in X.509 certificates along with the certificate validation process from a security perspective.
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 (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.
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 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 calls out where normative documents are needed.
The [I-D.blank-ietf-bimi], dated February 6, 2019 aka the “Assertion Record” specification, states as its objectives the following goals:
(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.
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:
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: Snowden disclosures show that nation-state adversaries have been able to mount such attacks. Unfortunately deployment of DNS protection through DNSSEC seems to be stalled.
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 attacks seem far fetched, the
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)” 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.
Experience using identity carrying certificates have identified several important issues. An adversary attempting to spoof an identity might try to exploit weaknesses in certificate issuance validation.
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:
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.
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 with additional guidelines specific for BIMI as described in these Guidelines for Issuance of Verified Mark Certificates v0.97.
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.
The Verified Mark Certificate issuance process builds upon the web Extended Validation (EV) certificates issuance guidelines, with appropriate extensions as described Guidelines for Issuance of Verified Mark Certificates v0.97. 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 FAQ, and the link for EU (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:
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 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).
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 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 that might be interested. Automated visual recognition of logos is a capability commercially available e.g. top 8 list.
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.
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 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 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.
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 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.
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 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.
One issue is the security of SVG. [RFC6170] specifies restrictions on the SVG to secure it:
Only images that meet these requirements from RFC6170 are acceptable for use with BIMI and must be validated by the CA/MVA.
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.
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.
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 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 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.
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” which noted that users have a hard time understanding security concepts. As noted earlier, subsequent research 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. 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. 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.
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.
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.
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].
| [I-D.blank-ietf-bimi] | Blank, S., Goldstein, P., Loder, T. and T. Zink, "Brand Indicators for Message Identification (BIMI)", Internet-Draft draft-blank-ietf-bimi-00, February 2019. |
| [I-D.brotman-ietf-bimi-guidance] | Brotman, A. and T. Zink, "Receivers Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Internet-Draft draft-brotman-ietf-bimi-guidance-00, February 2019. |