< draft-brotman-ietf-bimi-guidance-00.txt   draft-brotman-ietf-bimi-guidance-01.txt >
Network Working Group A. Brotman Network Working Group A. Brotman
Internet-Draft Comcast, Inc Internet-Draft Comcast, Inc
Intended status: Best Current Practice T. Zink Intended status: Best Current Practice T. Zink
Expires: August 10, 2019 Zink Magical Contraptions Expires: February 6, 2020 Zink Magical Contraptions
February 6, 2019 August 5, 2019
Receivers Guidance for Implementing Branded Indicators for Message Receivers Guidance for Implementing Branded Indicators for Message
Identification (BIMI) Identification (BIMI)
draft-brotman-ietf-bimi-guidance-00 draft-brotman-ietf-bimi-guidance-01
Abstract Abstract
This document is meant to assist receivers or other mailbox providers This document is meant to assist receivers or other mailbox providers
by providing guidance to implementing Brand Indicators for Message by providing guidance to implementing Brand Indicators for Message
Identification (BIMI). This document is a companion to the main BIMI Identification (BIMI). This document is a companion to the main BIMI
drafts which should first be consulted and reviewed. drafts which should first be consulted and reviewed.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 10, 2019. This Internet-Draft will expire on February 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
6.3. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 7 6.3. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 7
6.4. Basic flow example . . . . . . . . . . . . . . . . . . . 7 6.4. Basic flow example . . . . . . . . . . . . . . . . . . . 7
7. Domain Reputation . . . . . . . . . . . . . . . . . . . . . . 8 7. Domain Reputation . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Rolling up based upon domain vs organizational domain . . 9 7.1. Rolling up based upon domain vs organizational domain . . 9
8. Working with MVAs . . . . . . . . . . . . . . . . . . . . . . 10 8. Working with MVAs . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Resolving disputes . . . . . . . . . . . . . . . . . . . 11 8.1. Resolving disputes . . . . . . . . . . . . . . . . . . . 11
9. Troubleshooting BIMI . . . . . . . . . . . . . . . . . . . . 11 9. Troubleshooting BIMI . . . . . . . . . . . . . . . . . . . . 11
10. Public documentation . . . . . . . . . . . . . . . . . . . . 12 10. Public documentation . . . . . . . . . . . . . . . . . . . . 12
10.1. For Brands: . . . . . . . . . . . . . . . . . . . . . . 12 10.1. For Brands: . . . . . . . . . . . . . . . . . . . . . . 12
10.2. For users: . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. For users: . . . . . . . . . . . . . . . . . . . . . . . 12
11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Normative References . . . . . . . . . . . . . . . . . . . . 14 14. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Brand Indicators for Message Identification (BIMI) specification The Brand Indicators for Message Identification (BIMI) specification
introduces a method by which Mail User Agent (MUA, e.g, an email introduces a method by which Mail User Agent (MUA, e.g, an email
skipping to change at page 3, line 20 skipping to change at page 3, line 20
[BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Goals for BIMI 2. Goals for BIMI
As stated in other BIMI drafts, BIMI intends to advance email As stated in other BIMI drafts, BIMI intends to advance email
authentication by granting a sending party brand impressions as long authentication by granting a sending party brand impressions as long
as the message passes authentication mechanisms and and meets other as the message passes authentication mechanisms and and meets other
receiver qualifications (reputation, encryption, whitelisting, et receiver qualifications (reputation, encryption, whitelisting, et
cetera). DMARC currently has wide adoption by some of the cetera). DMARC currently has wide adoption by some of the
InternetaEUR[TM]s larger brands, but there is still a long tail of InternetA[cents]a'[not]a"[cents]s larger brands, but there is still a
small-to-medium size brands (and many large ones) that do not have long tail of small-to-medium size brands (and many large ones) that
it. Because BIMI provides a visual presence in the inbox, and do not have it. Because BIMI provides a visual presence in the
because visual impressions are desirable for brands, BIMI provides an inbox, and because visual impressions are desirable for brands, BIMI
incentive for marketers to spur DMARC adoption, whereas a concern provides an incentive for marketers to spur DMARC adoption, whereas a
purely from security may not. concern purely from security may not.
3. Should your site implement BIMI? 3. Should your site implement BIMI?
3.1. If your site satisfies the requirements, this is likely a "yes". 3.1. If your site satisfies the requirements, this is likely a "yes".
As email has evolved over the past three decades, it is no longer a As email has evolved over the past three decades, it is no longer a
medium of merely exchanging text, but of enabling people to build medium of merely exchanging text, but of enabling people to build
rich experiences on top of it. BIMI provides an incentive for brands rich experiences on top of it. BIMI provides an incentive for brands
to send email more securely because the desired behavior - a visual to send email more securely because the desired behavior - a visual
imprint in the inbox - first requires DMARC adoption. imprint in the inbox - first requires DMARC adoption.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
To alleviate this, receivers may wish to show logos only for domains To alleviate this, receivers may wish to show logos only for domains
that have organizational domains with strong DMARC policies. Or, if that have organizational domains with strong DMARC policies. Or, if
an organizational domain does not have a strong DMARC policy but a an organizational domain does not have a strong DMARC policy but a
subdomain does, then it may treat the organizational domain as if it subdomain does, then it may treat the organizational domain as if it
does have a strong DMARC policy so as to prevent a phisher or spammer does have a strong DMARC policy so as to prevent a phisher or spammer
from impersonating the brand or any of its subdomains. from impersonating the brand or any of its subdomains.
8. Working with MVAs 8. Working with MVAs
Email receivers need to know whether or not itaEUR[TM]s safe to Email receivers need to know whether or not
download and display an image. That is, an attacker could go through itA[cents]a'[not]a"[cents]s safe to download and display an image.
the trouble of creating a BIMI logo and uploading it, but the logo That is, an attacker could go through the trouble of creating a BIMI
may look visually similar to a real brand. For example, a spammer or logo and uploading it, but the logo may look visually similar to a
phisher could create a lookalike domain for a well-known brand such real brand. For example, a spammer or phisher could create a
as Paypal, then copy/paste (or slightly modify) the logo. lookalike domain for a well-known brand such as Paypal, then copy/
paste (or slightly modify) the logo.
To prevent this, an email receiver could choose to verify logos of To prevent this, an email receiver could choose to verify logos of
known brands by themselves (do it all in-house) and establish its own known brands by themselves (do it all in-house) and establish its own
internal processes, or it could use a Mark Verifying Authority (MVA). internal processes, or it could use a Mark Verifying Authority (MVA).
The receiver could then outsource the maintenance of the list of The receiver could then outsource the maintenance of the list of
trusted brands to the MVA, and simply download the list of brands and trusted brands to the MVA, and simply download the list of brands and
images from the MVA and display the logos in its email clients. images from the MVA and display the logos in its email clients.
However, even here a receiver would need to exercise caution. It However, even here a receiver would need to exercise caution. It
needs to ensure that MVAs follow best practices, respond to needs to ensure that MVAs follow best practices, respond to
complaints, and do a good job of vetting brands. If users ultimately complaints, and do a good job of vetting brands. If users ultimately
end up getting phished because they trust signals in the email end up getting phished because they trust signals in the email
client, then it is the email receiver that will suffer the brunt of client, then it is the email receiver that will suffer the brunt of
the complaints and loss of reputation, rather than the MVA. the complaints and loss of reputation, rather than the MVA.
Therefore, an email receiver still needs to track complaints from its Therefore, an email receiver still needs to track complaints from its
users, especially with respect to phishing and impersonation, and users, especially with respect to phishing and impersonation, and
then send the feedback back to the MVA. If an MVA still generates then send the feedback back to the MVA. If an MVA still generates
too many complaints, this could be indicative of a rogue MVA (one too many complaints, this could be indicative of a rogue MVA (one
that intentionally signs up malicious accounts), or a that intentionally signs up malicious accounts), or a
aEURoesloppyaEUR&#157; MVA (one with internal processes that not A[cents]a'[not]Ae"sloppyA[cents]a'[not]A&#157; MVA (one with internal
rigorous enough, or are designed to maximize revenue at the cost of processes that not rigorous enough, or are designed to maximize
lax security). revenue at the cost of lax security).
An email receiver should use multiple MVAs to reduce the risk of An email receiver should use multiple MVAs to reduce the risk of
becoming too reliant upon a single MVA in case they have to stop becoming too reliant upon a single MVA in case they have to stop
using it, and therefore lose many dozens, hundreds, or thousands of using it, and therefore lose many dozens, hundreds, or thousands of
images with no replacement and thereby contributing to user images with no replacement and thereby contributing to user
dissatisfaction confusion. Furthermore, because MVAs may be revoked, dissatisfaction confusion. Furthermore, because MVAs may be revoked,
brands may wish to diversify their own risk by getting certified by brands may wish to diversify their own risk by getting certified by
at least two MVAs. The reason for doing this is that if the MVA they at least two MVAs. The reason for doing this is that if the MVA they
use ever gets revoked by an email receiver because of its bad use ever gets revoked by an email receiver because of its bad
practices, then their own brand will suffer penalties (not having a practices, then their own brand will suffer penalties (not having a
skipping to change at page 11, line 12 skipping to change at page 11, line 12
For this reason, brands are encouraged to get certified at multiple For this reason, brands are encouraged to get certified at multiple
MVAs, and receivers are encouraged to use multiple MVAs. MVAs, and receivers are encouraged to use multiple MVAs.
8.1. Resolving disputes 8.1. Resolving disputes
From time to time, disputes may arise between brands where one brand From time to time, disputes may arise between brands where one brand
says that another is infringing on its logo. says that another is infringing on its logo.
A brand owner would want to have all email receivers stop showing A brand owner would want to have all email receivers stop showing
logos for the infringing brand because it could damage its own logos for the infringing brand because it could damage its own
brandaEUR[TM]s reputation. However, an email receiver is not brandA[cents]a'[not]a"[cents]s reputation. However, an email
necessarily in a good position to determine what constitutes receiver is not necessarily in a good position to determine what
legitimate usage of a logo, nor determine ownership of a logo, nor constitutes legitimate usage of a logo, nor determine ownership of a
may want the legal risk associated with making this determination. logo, nor may want the legal risk associated with making this
determination.
Therefore, email receivers are strongly encouraged to partner with Therefore, email receivers are strongly encouraged to partner with
Dispute Resolution Agencies. These agencies specialize in copyright Dispute Resolution Agencies. These agencies specialize in copyright
infringement resolution. An affected party would then contact the infringement resolution. An affected party would then contact the
Dispute Resolution Agency, rather than the email receiver, who would Dispute Resolution Agency, rather than the email receiver, who would
then make the decision about if use of the logo were legitimate. then make the decision about if use of the logo were legitimate.
Then, they would publish the result of the dispute publicly where it Then, they would publish the result of the dispute publicly where it
could be viewed by anyone. could be viewed by anyone.
MVAs should respect the decision of the courts and any brand found to MVAs should respect the decision of the courts and any brand found to
be infringing ought to be removed from their list of domains for be infringing ought to be removed from their list of domains for
which they load BIMI logos for. The issuing MVA of the infringing which they load BIMI logos for. The issuing MVA of the infringing
brandaEUR[TM]s BIMI Certificate should formally revoke it. However, brandA[cents]a'[not]a"[cents]s BIMI Certificate should formally
this is not guaranteed in the case of a rogue MVA or a sloppy MVA. revoke it. However, this is not guaranteed in the case of a rogue
Therefore, email receivers should also pay attention to the Dispute MVA or a sloppy MVA. Therefore, email receivers should also pay
Resolution Agencies, and any results that they say are infringing attention to the Dispute Resolution Agencies, and any results that
should be prevented from loading in their email clients. The email they say are infringing should be prevented from loading in their
receiver should also keep track of how often disputes occur and are email clients. The email receiver should also keep track of how
found against various MVAs, as an MVA with too many disputes ruled often disputes occur and are found against various MVAs, as an MVA
against it could be evidence of a sloppy MVA or a rogue MVA. with too many disputes ruled against it could be evidence of a sloppy
MVA or a rogue MVA.
9. Troubleshooting BIMI 9. Troubleshooting BIMI
There are several factors to consider for email receivers on things There are several factors to consider for email receivers on things
that can go wrong, below are a handful of considerations: that can go wrong, below are a handful of considerations:
o Failing to verify BIMI certs when they otherwise should be. This o Failing to verify BIMI certs when they otherwise should be. This
can be caused by: can be caused by:
o Not having the key to a corresponding MVA o Not having the key to a corresponding MVA
skipping to change at page 12, line 28 skipping to change at page 12, line 30
escalation channels) are important for investigation. escalation channels) are important for investigation.
10. Public documentation 10. Public documentation
10.1. For Brands: 10.1. For Brands:
It is ideal to publish the criteria that is used by your site to It is ideal to publish the criteria that is used by your site to
determine when BIMI will be displayed. It is fine to say that you determine when BIMI will be displayed. It is fine to say that you
use some internal domain reputation metrics as additional criteria to use some internal domain reputation metrics as additional criteria to
determine whether or not a logo should be displayed, and it determine whether or not a logo should be displayed, and it
isnaEUR[TM]t necessary to give away the exact nature of the algorithm isnA[cents]a'[not]a"[cents]t necessary to give away the exact nature
other than to say "You must maintain good sending practices." of the algorithm other than to say "You must maintain good sending
practices."
If you use an explicit whitelist, a site may want to list the minimum If you use an explicit whitelist, a site may want to list the minimum
requirements, and the method of applying to be whitelisted. requirements, and the method of applying to be whitelisted.
Similarly, a provider may wish to state what type of activity will Similarly, a provider may wish to state what type of activity will
revoke the decision to display logos previously approved. revoke the decision to display logos previously approved.
10.2. For users: 10.2. For users:
BIMI is not meant to instill additional trust in messages, and it is BIMI is not meant to instill additional trust in messages, and it is
important to make this known to your users. All messages, even those important to make this known to your users. All messages, even those
with logos, should still be treated with (mild) skepticism, and any with logos, should still be treated with (mild) skepticism, and any
action regarding the message should still be individually evaluated. action regarding the message should still be individually evaluated.
ItaEUR[TM]s possible for a site that has a high trust value to become ItA[cents]a'[not]a"[cents]s possible for a site that has a high trust
compromised and send fraudulent messages that could compromise a value to become compromised and send fraudulent messages that could
useraEUR[TM]s system. Ensure your customers have a place that compromise a userA[cents]a'[not]a"[cents]s system. Ensure your
documents BIMI and demonstrates how to check messages for fraud. customers have a place that documents BIMI and demonstrates how to
check messages for fraud.
11. Appendix 11. Appendix
11.1. Glossary 11.1. Glossary
o MUA - Mail User Agent - The application used to read messages by o MUA - Mail User Agent - The application used to read messages by
the end user. This could be a thick client or a web-based the end user. This could be a thick client or a web-based
application. application.
o MTA - Mail Transfer Agent - Software used to transfer messages o MTA - Mail Transfer Agent - Software used to transfer messages
between two systems, typically between two sites, using SMTP as between two systems, typically between two sites, using SMTP as
the protocol. the protocol.
skipping to change at page 14, line 16 skipping to change at page 14, line 17
o BIMI Certificates - An Extended Validation Certificate is used in o BIMI Certificates - An Extended Validation Certificate is used in
conjunction with BIMI to create a place where information conjunction with BIMI to create a place where information
pertaining to iconography for a sending domain can be securely pertaining to iconography for a sending domain can be securely
verified. In the case of BIMI, hashes for an MVA-approved set of verified. In the case of BIMI, hashes for an MVA-approved set of
iconography will be stored in a field within the certificate. iconography will be stored in a field within the certificate.
This should allow a receiver site to validate the retrieved This should allow a receiver site to validate the retrieved
imagery before putting the BIMI image URI into the message imagery before putting the BIMI image URI into the message
headers. headers.
o Terry Zink - Alex BrotmanaEUR[TM]s best friend. o Terry Zink - Alex BrotmanA[cents]a'[not]a"[cents]s best friend.
12. Contributors 12. Contributors
TBD TBD
13. References 13. References
The full BIMI verification spec can be found at: The full BIMI verification spec can be found at:
<https://github.com/authindicators/rfc-brand-indicators-for-message- <https://github.com/authindicators/rfc-brand-indicators-for-message-
identification> identification>
 End of changes. 13 change blocks. 
39 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/