Network Working Group A. Brotman Internet-Draft Comcast, Inc Intended status: Standards Track 20 June 2025 Expires: 22 December 2025 BIMI on an Independent MUA draft-brotman-bimi-mua-00 Abstract This document describes a method by which a receiving MTA may insert Brand Indicators for Message Identification (BIMI) headers into a message in such a way that a third party MUA can not only use the information in those headers but also validate that the headers were inserted by the MTA. 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 22 December 2025. Copyright Notice Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Brotman Expires 22 December 2025 [Page 1] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Validation Information . . . . . . . . . . . . . . . . . . . 3 3. BIMI-Receiver-Signature . . . . . . . . . . . . . . . . . . . 4 3.1. Public Key Publishing . . . . . . . . . . . . . . . . . . 5 4. MUA Validation . . . . . . . . . . . . . . . . . . . . . . . 6 5. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Wildcard Revocation . . . . . . . . . . . . . . . . . . . 7 5.1.1. Multi-domain Revocation . . . . . . . . . . . . . . . 7 5.1.2. Multi-selector Revocation . . . . . . . . . . . . . . 7 5.1.3. Public Key Revocation/Rotation . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Threat Concerns . . . . . . . . . . . . . . . . . . . . . 8 6.1.1. Injection of Headers to An Unaware Mailbox Provider . . . . . . . . . . . . . . . . . . . . . . 8 6.1.2. IMAP Append . . . . . . . . . . . . . . . . . . . . . 8 6.1.3. Signature Replay . . . . . . . . . . . . . . . . . . 8 6.1.4. Revocation . . . . . . . . . . . . . . . . . . . . . 8 6.2. Key Separation . . . . . . . . . . . . . . . . . . . . . 8 6.3. Header Removal . . . . . . . . . . . . . . . . . . . . . 8 6.4. DNS/Key caching . . . . . . . . . . . . . . . . . . . . . 9 6.5. DNS Query Data . . . . . . . . . . . . . . . . . . . . . 9 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 7.1. Multi-Domain MBP . . . . . . . . . . . . . . . . . . . . 9 8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normal Operational Steps . . . . . . . . . . . . . . . . 9 8.2. Revoked Operational Steps . . . . . . . . . . . . . . . . 10 8.3. Sample headers . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Normative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Brand Indicators for Message Identification (BIMI) describes a method to enable Domain Owners to coordinate with Mailbox Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents (MUAs) in the display of brand-specific Indicators (e.g., logos) next to properly authenticated messages. BIMI relies on DMARC, which in turn relies on one of SPF or DKIM validation for the message in question, and it is generally accepted that an MTA is best positioned to do the SPF and DKIM validation that underpin DMARC since it has the access to the data necessary for such Brotman Expires 22 December 2025 [Page 2] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 validation. An MUA almost certainly cannot perform SPF validation on a message, as it will not know the sending IP of the message (short of attempting to interpret Received headers), and an MUA could only perform DKIM validation on a message if the MTA has not altered the DKIM-protected parts of the message. This makes the simplest path to the display of a BIMI Indicator one where the MTA performs the required checks for DMARC and BIMI and records the results of those checks in a way that can be accessed by the MUA. BIMI makes no requirement that the MTA handling a message and the MUA reading and displaying it are operated by the same entity. In cases where a mailbox holder uses their MBP's MUA to read the contents of their mailbox, it is a relatively simple matter for the MTA and MUA to interoperate in a way in which the display of the BIMI Indicator can be controlled by the MBP. What is less simple is the interoperability between an MBP's MTAs and message stores and an independent, or third-party, MUA. In this scenario, there must exist a standard way for an MTA to communicate BIMI and DMARC validation results to the MUA in a way that can be verified by the MUA. In addition, the MBP through its message store may desire to be able to indicate that a BIMI Indicator and/or its Evidence Document has been revoked if circumstances require. This document describes a method for achieving interoperability between a MBP's MTAs and message stores, and a third-party MUA. Without this link, an attacker could potentially insert messages with existing headers through some other means, SMTP and IMAP are examples here. Using this verifiable method allows for the MUA to understand the validation at the MTA layer. 2. Validation Information The receiving entity may add two headers, BIMI-Location and BIMI- Indicator. These two headers are meant to aid the MUA with the location of the BIMI-related information, as well as base64-encoded SVG image data. They could also insert an Authentication-Results header at this stage. Additionally, a receiver employing this method MUST add another header to the message, BIMI-Receiver-Information. This will contain a date-time (from [RFC5322]), and sha256-encoded hash from the local part of the recipient, and then the domain (From the RFC5321 RCPT TO command): BIMI-Receiver-Information: date: date-time ; rcpt: sha256-local @ domain Brotman Expires 22 December 2025 [Page 3] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 date-time: RFC5322 domain: RFC5321 sha256-local: 64( HEXDIG ) An example might be: BIMI-Receiver-Information: date: Tue, 25 Feb 2023 01:05:55 +0000 ; rcpt: 6d9010b2b7a1483b256ae7477738dba7c530bd9ba53db1d6691441e74b83608 a@isp.net A MBP may choose to add this data without the signature specified below. However, as the data cannot be verified via the signature, the MUA may find the data within the header unsatisfactory to be used. NOTE: Changed to 5321, instead of 5322 3. BIMI-Receiver-Signature The MTA or other entity that performed the BIMI validation of the message MUST, if the message passed all BIMI validation checks, insert a BIMI-Receiver-Signature header constructed in a manner consistent with the creation of a DKIM-Signature header as defined in [RFC6376]. This header MUST include all the BIMI-Location, BIMI- Selector, and BIMI-Receiver-Information headers as headers that were signed by this signature. Additionally, the signer should oversign the headers included as part of this signature as defined in [RFC6376]. CLARIFICATION: Is this Receiver-Signature header useful without the other headers? Today, not all MBPs insert these headers. Can this still be useful? This signature will be validated by the MUA in the same manner that a DKIM-Signature header is validated, and successful validation of this header will indicate that the receiving domain inserted the signed headers. Brotman Expires 22 December 2025 [Page 4] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 The public key to support this signing activity will be published in the DNS at a location one or more levels below the name "_bimi.signingDomain", where "signingDomain" is the domain associated with the address in the RCPT TO command. By utilizing a different "namespace", this prevents this particular key from being used in DKIM Replay attacks. For example, an MBP named "isp.net" might publish its public key at "sel_sign._local._bimi.isp.net". For the purposes of this document, we will refer to "sel_sign" as the "True Selector". The selector specified in the s= tag of this signature will be a pseudo-selector constructed by prepending the FQDN domain from the the BIMI discovery to the "True Selector". In the INFORMATIVE EXAMPLE of a BIMI-Receiver-Signature header shown below, the s= tag is assigned the value "marketing.example.org.sel_sign", which means that the BIMI information for the message was found at the domain "marketing.example.org". DISCUSS: Terminology around which domain is used above, and how we reference it. DISCUSS: Other headers? Other information? BIMI-Receiver-Signature: v=BIMI1; d=isp.net; s=marketing.example.org.sel_sign; c=canonicalization; h=BIMI- Location:BIMI-Selector:BIMI-Receiver-Information; b=; t=timestamp The public key used for validation by the MUA would be: marketing.example.org.sel_sign._local._bimi.isp.net The mechanics of the public key publishing are covered in sections below. 3.1. Public Key Publishing While the above method describing "pseudo-selectors" might seem to require that isp.net publish an infinite number of DKIM public keys in order to support validation of its BIMI-Receiver-Signature headers, that is not the case. Instead, validation of these signature headers will rely on publishing a DNS wildcard record, while revocation of BIMI logos will rely on the publishing of empty records to match the domains for which the MBP no longer wishes to support validation of BIMI logos. Brotman Expires 22 December 2025 [Page 5] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 As mentioned in the previous section, the MBP will publish its public key for supporting validation of BIMI-Receiver-Signatures at the name matching this pattern: ._local._bimi. In the example above that would mean publishing a DKIM public key as follows: sel_sign._local._bimi.isp.net TXT "v=BIMI1; p=" To support validation of its signatures where the selector is the "pseudo-selector" described in the previous section, the MBP will also publish the following DNS wildcard record: *.sel_sign._local._bimi.isp.net CNAME sel_sign._local._bimi.isp.net. When the MUA performs a lookup, the wildcard MUST match and provide the MUA with the proper public key to validate the signature. 4. MUA Validation NOTE: Stub, needs elaboration As with DKIM, the MUA will use the cryptographic signature to validate the protected contents. Additionally, the MUA may use a sha-256 hash to validate the message and signature are meant for the recipient using the MUA. By validating the recipient, this could aid with replay protection. 5. Revocation There could exist any number of reasons for a receiving entity to no longer desire to display iconography related to a given sending domain. This could include certificate revocation from the CA, diminished local reputation, extensive abuse reports, certificate expiration, or anything else. In the case where this happens, the MBP (again, isp.net) can publish a NULL record at the location where the domain would normally match a wildcard. The MBP may optionally choose to include a string as to the reason for revocation by utilizing the r tag in the record. If we also use marketing.example.org with a selector of "foo", this MUST appear as: foo._s.marketing.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' foo._s.marketing.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;"r=Reason String;"' Brotman Expires 22 December 2025 [Page 6] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 The DNS response MUST not include a functional public key that could be used to validate the signature. If compared to the wildcard DNS entry defined earlier, there will no longer be a public key that can be used for validation. The DNS record MUST contain only a v tag, MAY contain an optional r tag, and MUST NOT contain a p (public key) tag. This should ensure the MUA is no longer able to retrieve the public keys necessary to validate the signature. In this case, the MUA MUST NOT utilize the headers, even though they do still exist in the stored message. See the Appendix for how revocation would look in practice. 5.1. Wildcard Revocation Three situations could exist here. A MBP would like to revoke multiple third-level domains for a single apex domain. Another could be that the MBP would like to rotate older keys. 5.1.1. Multi-domain Revocation In a case where the domain example.org sends messages as: marketing.example.org billing.example.org And the MBP would like to revoke for the entirety of example.org, a wildcard record could be published to match multiple: example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' *.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' 5.1.2. Multi-selector Revocation If the MBP would prefer to revoke all selectors for a given domain, it could be published with a wildcard: *._s.marketing.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' 5.1.3. Public Key Revocation/Rotation The MBP could determine that an older key needs to be retired. In this case the MBP could either remove the DNS record, or continue publishing without a valid public key attached: Brotman Expires 22 December 2025 [Page 7] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' *.sel_sign._local._bimi.isp.net CNAME sel_sign._bimi.isp.net For any MUA attempting to validate a signature, this action SHOULD fail. The MBP should rotate keys far ahead of removal of older keys so that recent messages are not disassociated with the imagery the MBP believes should be displayed. An MUA SHOULD check for revocation daily or upon receipt of the first message for a domain. If the MUA does not intend to display the logo for a given message, it MAY NOT check for revocation. This may happen if the MUA only displays the logo when the message is opened (vs in the "list view"). 6. Security Considerations 6.1. Threat Concerns There are a number of concerns relating to how an independent MUA may use some of this information, or more important, how an attacker may attempt to cause an MUA to improperly display iconography for a user. This document is attempting to address these potential attacks. 6.1.1. Injection of Headers to An Unaware Mailbox Provider An attacker could attempt to inject a message via normal SMTP methods, however, the message would contain headers that the MUA may believe were added by the receiving Mailbox Provider. 6.1.2. IMAP Append An attacker could insert messages into a mail store via IMAP commands, and given a reasonable set of information points could induce an MUA to display a logo. 6.1.3. Signature Replay 6.1.4. Revocation 6.2. Key Separation The key used to sign these BIMI headers MUST NOT be shared with another portion of the receiving platform. 6.3. Header Removal Any MBP receiving these headers intact SHOULD remove these and perform their own evaluations. Brotman Expires 22 December 2025 [Page 8] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 NOTE: Ensure that core document specifies the same for BIMI-related headers 6.4. DNS/Key caching Care should be taken not to cache public keys retrieved for an excessive amount of time. It's presumed that the MBP has a good reason to revoke the display of related imagery. NOTE: Require MUA only retain data for TTL duration? 6.5. DNS Query Data If the MUA queries DNS each time a message is loaded, it's conceivable that the DNS server owner could correlate some information about a user. It's not entirely clear if that data could be tied to a specific user, or what value this data may have. 7. Other Considerations 7.1. Multi-Domain MBP There exist a large number of MBPs that accept mail for multiple domains. It could be that there is a primary domain with some side aliases, or a large hosting company. These types of entities may wish to explore using a DNAME to link the data between these various domains. One possible solution could be to do something such as: _local._bimi.companyA.com DNAME _local._bimi.isp.net This would allow for the same sharing of keys, as well as revocation information across the domains, while only managing one set of data. 8. Appendix A For purposes below, sending is marketing.example.org, MBP is isp.net, and selector is sel_sign. 8.1. Normal Operational Steps * ESP sends message to MBP containing appropriate headers for BIMI usage * MBP performs DKIM/SPF/DMARC steps * Presuming prior step works properly, MBP evaluates BIMI * Based on localized requirements, MBP adds headers to email - BIMI-Location - BIMI-Indicator * MBP additionally adds header specified in this document Brotman Expires 22 December 2025 [Page 9] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 - BIMI-Receiver-Information - Includes time of receipt, sha256 of local rcpt, and the "@isp.net" portion * MBP signs all three headers using DKIM-style cryptography - Adds new header containing hash, as well as s/d attributes * ... * MBP stores message in platform * MUA retrieves message from message store * User opens message or MUA uses data during list view * MUA inspects looking for BIMI data * MUA sees signature - MUA verifies that the destination email address matches the signing domain - Looks for public keys at marketing.example.org.sel_sign._local._bimi.isp.net - Matches wildcard at *.sel_sign._local._bimi.isp.net * MUA validates signature * MUA displays BIMI logo as needed (list or message view) 8.2. Revoked Operational Steps * ESP sends message to MBP containing appropriate headers for BIMI usage * MBP performs DKIM/SPF/DMARC steps * Presuming prior step works properly, MBP evaluates BIMI * Based on localized requirements, MBP adds headers to email - BIMI-Location - BIMI-Indicator * MBP additionally adds header specified in this document - BIMI-Receiver-Information - Includes time of receipt, sha256 of local rcpt, and the "@isp.net" portion * MBP signs all three headers using DKIM-style cryptography - Adds new header containing hash, as well as s/d attributes * ... * MBP stores message in platform * MUA retrieves message from message store * User opens message or MUA uses data during list view * MUA inspects looking for BIMI data * MUA sees signature - MUA verifies that the destination email address matches the signing domain - Looks for public keys at selector.marketing.example.org.sel_sign._local._bimi.isp.net - MUA sees a value of "v=BIMI1;" * MUA does NOT display logos for this message (and the domain as a whole) Brotman Expires 22 December 2025 [Page 10] RFC draft-brotman-bimi-mua-00 BIMI-MUA June 2025 8.3. Sample headers BIMI-Receiver-Signature: s=our_selector.marketing.example.org.sel_sig n;d=isp.net;p= BIMI-Receiver-Information: date: Tue, 25 Oct 2022 15:14:12 +00:00 ; rcpt=d1bc8d3ba4afc7e109612cb73acbdddac0 52c93025aa1f82942edabb7deb82a1@isp.net BIMI-Location: v=BIMI1;a=https://bimi.marketing.example.org/bimi/evidence.pem (https://bimi.marketing.example.org/bimi/evidence.pem); l=https://bimi.marketing.example.org/bimi/logo.svg (https://bimi.marketing.example.org/bimi/logo.svg) BIMI-Indicator: Authentication-Results: spf=pass marketing.marketing.example.org; dkim=pass (signature was verified) header.d=marketing.example.org; dmarc=pass header.from=marketing.example.org; bimi=pass header.d=marketing.example.org header.selector=our_selector DKIM- Signature: d=marketing.example.org;s=d_s;h=BIMI- Selector:From:To:Date:Message-Id; bh=;b= BIMI-Selector: v=BIMI1;s=our_selector 9. Contributors 10. Notes 11. TODO * Cleanup notes * Missing a number of references * Enhance MUA Validation stub 12. References 13. Normative References [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [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, . Author's Address Alex Brotman Comcast, Inc Email: alex_brotman@comcast.com Brotman Expires 22 December 2025 [Page 11]