Independent Stream W. Chuang Internet-Draft Google, Inc. Intended status: Experimental 10 July 2023 Expires: 11 January 2024 Tolerating Mailing-List Modifications draft-chuang-mailing-list-modifications-00 Abstract Mailing-lists distribute email to multiple recipients by forwarding and potentially modifying messages to document the distribution to the recipients. Unfortunately forwarding breaks SPF (RFC7208) authentication and message modification breaks DKIM (RFC6376) authentication. This document is based on draft-chuang-replay- resistant-arc which is built on ARC (RFC8617) with extensions to tolerate common mailing-list message modifications. This specification characterizes the mailing-list transforms such that a receiver can reverse them to enable digital signatures verification and attribution of the message content. These message modifications are: 1) prepending a description string to the Subject header, 2) rewriting the From header, 3) removing the original DKIM-Signature and 4) appending a footer to the message body. 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 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Chuang Expires 11 January 2024 [Page 1] Internet-Draft Mailing-List Modifications July 2023 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. Table of Contents 1. **Introduction ** . . . . . . . . . . . . . . . . . . . . . . 2 1.1. *Terminology and Definitions* . . . . . . . . . . . . . . 3 2. *Algorithm* . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Forwarder Characterization . . . . . . . . . . . . . . . 4 2.2. Header Rewriting . . . . . . . . . . . . . . . . . . . . 4 2.3. Message Footer . . . . . . . . . . . . . . . . . . . . . 5 2.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 7 3. **Examples ** . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Originator ==> First Mailing-List ==> Second Mailing-List ==>Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. **Introduction ** Mailing-lists have long complicated email authentication. They break SPF (RFC7208) authentication due to forwarding and break DKIM (RFC6376) authentication due to message modification that used to identify the mailing-list. This specification along with draft- chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/draft- chuang-replay-resistant-arc/) provides methods to restore authentication even in the presence of forwarding and message modification. draft-chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/) provides a method to authenticate email when it has been forwarded arbitrarily many times, and a limited means to tolerate message modification, but doesn't attribute which party in the message flow contributed which content. Malicious appearing content is then attributed to all parties in the mail flow. Moreover, mailing-lists sometimes rewrite DKIM-Signatures making it impossible to restore the original DKIM authentication. This specification improves draft- chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/draft- chuang-replay-resistant-arc/) by enabling attribution of email content to its author. Chuang Expires 11 January 2024 [Page 2] Internet-Draft Mailing-List Modifications July 2023 The approach in this document is highly opinionated to eliminate changes to messages that don't go through mailing-lists and to lessen implementation burden upon mailing-lists and receivers by supporting only common case mailing-list mutations. At origination, it is sufficient to sign a message with a DKIM signature as typically done already. It does ask those mailing-lists that wish to use this specification to characterize the modifications it performs at each forwarding step. The goal is to permit receivers to reverse the modification so that the message hash can be recovered and the prior signature verified at each forwarding step, be it from DKIM or ARC. This allows the receiver to determine which forwarder or the originator contributed which content, in the received message. This specification uses the ARC (RFC8617) framework to describe each forwarder, and then record the mutation performed at each forwarding step. Consequently this attribution enables more precise reputation systems and UI features. The supported modifications are: 1) prepending a description string to the Subject header, 2) rewriting the From header, 3) rewriting the original DKIM-Signature and 4) appending a footer to the message body. 1.1. *Terminology and Definitions* 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]. 2. *Algorithm* The specification in this document is divided into procedures computed at the mailing-list forwarder and at the receiver. For both, this assumes that the forwarder or receiver steps in draft- chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/draft- chuang-replay-resistant-arc/) have already been computed. The receiver steps in particular are variable length corresponding to the depth of the ARC sets. At each ARC set corresponding to some forwarder, the receiver computes any reversing procedure described later for any described mailing-list mutations to obtain the message hash of the message as seen at the inbound of the mailing-list. This hash is equivalent to that at outbound of the prior sender. If that sender is the originating sender, it may have a DKIM signature, and if it is a forwarder it may have ARC message-signature. That signature MUST verify correctly, otherwise this is considered a signature verification failure by this specification. Interpretation of that failure is described later. Chuang Expires 11 January 2024 [Page 3] Internet-Draft Mailing-List Modifications July 2023 2.1. Forwarder Characterization Conformant forwarders characterize message mutations to enable receivers to interpret mutations and potentially verification failures. A description is added as a tag-value to the ARC-Message- Signature. The mutator description tag is "m" and has the following values: mailinglist: Describes a forwarder that distributes messages to multiple recipients and any modification conforms to the specification in this document. Consequently signature validation failures are described as "fail". gateway Optional mutating forwarder that works on behalf of the originating sender or final receiver. The receiver is presumed to have an established trust model with the gateway outside of this document and, and validation failure result is interpreted by the receiver. The receiver with such an arrangement MUST NOT use this description to detect the existence of such a relationship. However a gateway forwarder may provide a description for human operators to interpret gateway's actions. generic Optional self-description for a generic mutator. This document imposes no judgment on signature validation failures but the description may help a human operator interpret the actions of the forwarder. none Conformant forwarders that do not mutate the message declares their participation and lack of mutation with none value. For example: ARC-Message-Signature: i=1, m=mailinglist,... Receivers use this mutator description tag to interpret the forwarder's action and whether they followed the guidelines in this specification. If the forwarder promised that they did, then it makes it possible to enforce a validation failure that protects that forwarder. 2.2. Header Rewriting A mailing-list forwarder that rewrites a Subject, From or DKIM- Signature headers can store the prior values by substituting a modified header with the prior value. Moreover the header name retains the original capitalization, its place with respect to other headers, and is not ambiguous if there are multiple headers of the same name. First the bottoms-up line count of all headers is Chuang Expires 11 January 2024 [Page 4] Internet-Draft Mailing-List Modifications July 2023 computed. Then all headers to be rewritten are collected, ordered by position to be prepended to the headers list and given a bottoms-up line count position. It is assumed that the prior header has the following format:
: The conserved header name is prefixed with a "Prior-". Then an ARC instance number tag "i" i.e. "=<#>," and line count tag "l" i.e. "l=: i=<#>,l=, For example: Prior-Subject: i=1,l=5, Meeting on the 5th Prior-Dkim-Signature: i=2,l=3, d=example.com,b=... This stores the prior header in a format that SHOULD be ignored by subsequent forwarders, and if not then will cause a verification failure. The forwarder then rewrites or deletes the header as before by prepending the rewritten header to the message or skipping prepending for deletion. To protect the integrity of these headers, these headers are hashed separately from ARC-Message-Signature "h" header list. The forwarder takes the header hash, then hashes the "Prior-" header in bottoms up order as found in the headers. This specification calls for the rewritten header hash to be explicitly added to the ARC-Message-Signature with a tag "hh". Conformant forwarders even without mailing-lists mutations MUST report header hash explicitly to better differentiate and tolerate body modifications when verifying headers. To reverse the rewriting or deletion of headers, all "Prior-" headers are collected at the given ARC instance number. The prior header name is extracted from the "Prior-" header, and the original value extracted and restored. The rewritten header at the line count position and matching header is deleted in top down order. 2.3. Message Footer Mailing-lists may choose to add a message footer to the body of the message to notify the recipient of the mailing-list distribution action and conformant mailing-list will describe this mutation to the receiver. One method is to append the footer text to all content- type text in the top level of mime-part "multipart/alternative". Another method is to append a new successor mime-part for a mime-part "multipart/mixed", and that mime-part contains the footer as a Chuang Expires 11 January 2024 [Page 5] Internet-Draft Mailing-List Modifications July 2023 content-type text. If the message is not mime formatted, the entire body is treated as text and the mailing-list may append a text footer at the bottom of the message. Conformant mailing-list forwarders characterize these changes with a new "Content-footer" header. It contains a list of comma separated tag-values using the formatting specifications in DKIM. The first of these is an ARC set instance number describing which forwarder added the header. When the mailing-list appends a text part, the receiver characterizes it with the beginning and ending byte offset of the mime-part or message-body if MIME unformatted. If the mailing-list adds a text mime-part as footer, it describes the mime part with its purpose tag-value. The Content-footer header is added to the mime- part for MIME formatted messages, and to the message headers for unformatted messages. To protect the integrity of the header, in the latter case, the Content-footer is hashed along with "Prior-" headers in the same bottoms up order. In the former case, Content-footer headers added to the message-body are protected by the message body hash. The following are the Content-footer header tag-values: i Instance tag. Must be the first tag-value. The value contains the instance number b Footer beginning offset in bytes from the start of the text mime- part or message-body if no MIME unformatted. MUST always appear with a footer ending offset. e Footer ending offset in bytes from the start of the text mime-part or message-body if no mime unformatted. MUST always appear with a footer beginning offset. m Mime-part purpose description. If the added mime-part contains the text footer, then the value is "footer". If the added mime- part is "multipart/mixed" and meant to support adding the text footer, then the value is "mixed". If the text footer is appended, then this tag-value is not added. For example: Content-footer: i=1, b=100, e=200 Content-footer: i=2, m=footer To reverse the footer addition, the receiver looks at the headers to see if the message is MIME formatted. If not, the receiver looks for a "Content-footer" in the headers. If so, the receiver looks for "Content-footer" in the MIME tree content headers. For each "Content-footer" found header at the current ARC set instance, it reverses the footer mutation. For offset values designated by Chuang Expires 11 January 2024 [Page 6] Internet-Draft Mailing-List Modifications July 2023 beginning and ending offset tags, it removes the text from that mime- part or the message-body designated. For a mime-part text footer, it deletes it along with any supporting "multipart/mixed" mime-part. Then the receiver deletes the Content-footer header from the updated message if not done so already. 2.4. Validation The receiver verifies prior ARC sets per the procedure described in draft-chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/ draft-chuang-replay-resistant-arc/). In addition, the receiver validates the ARC sets starting from the largest instance number found to the smallest. First the receiver verifies the given instance ARC-Message-Signature or DKIM-Signature as appropriate. Then the receiver computes the rewritten header hash taking the header hash computed by ARC-Message-Signature at the given instance number or DKIM-Signature. Then the hash is taken for "Prior-" headers and "Content-footer" header if found in the headers at the current ARC set instance number and all prior ones. This is verified against the header hash value associated with the tag "hh", reporting signature failure if it mismatches. Next the receiver determines whether it needs to reverse any header or footer mutations at that ARC set instance by looking for the ARC- Message-Signature mutation tag "m=". For values of "mailinglist", it attempts to reverse mutations keeping the resulting message so that further validations are possible. The receiver attempts to provide header reversing procedures given in "Header Rewriting" section and body reversing procedures given in "Message Footer" section. For values "gateway" the receiver MAY apply local policy to interpret subsequent validation failures. For all other mutation tag "m" values, it assumes no mutations are present or outside the scope of mailing-list modifications. In addition, the originating sender's DKIM-signature or ARC-Message- Signature MUST successfully verify. If so and all prior signatures verify, then the result is a "pass". Verification failures are subject to interpretation in "Footer Characterization" section, and potentially indicate a "fail". The result of this procedure is written in ARC-Authentication-Result with a method named "reverse" as the REVERSE result. Chuang Expires 11 January 2024 [Page 7] Internet-Draft Mailing-List Modifications July 2023 This specification modifies draft-chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/) PATH results to take into account the REVERSE result. At each ARC set instance where PATH recursively combines the local DARA (or SeRCi) results, if REVERSE reports "fail" then the PATH result reports "fail". Because _REVERSE _combined with_ _DARA_ _represents a higher bar of verification than DARA alone, the receiver MAY apply local policy when interpreting the PATH result. 3. **Examples ** 3.1. Originator ==> First Mailing-List ==> Second Mailing-List ==>Receiver This message is sent through two mailing-lists to some receiver. The originating sender creates and signs a message as follows: From: john.doe@example.com DKIM-Signature: d=example.com Subject: A really big announcement It's Jane Doe's birthday tomorrow! The first mailing-list adds a Subject header prefix and message-body footer, and denotes this using the procedures and headers specified in this document. Content-footer: i=1, b=34, e=78 From: school@mailinglist.example.com DKIM-Signature: d=mailinglist.example.com Subject: [school list] A really big announcement Prior-From: i=1,l=5, john.doe@example.com Prior-DKIM-Signature: i=1,l=4, d=example.com Prior-Subject: i=1,l=3, A really big announcement It's Jane Doe's birthday tomorrow! ============ This is the school mailing-list. The second mailing-list adds a Subject header prefix and message-body footer, and denotes this using the procedures and headers specified in this document. Chuang Expires 11 January 2024 [Page 8] Internet-Draft Mailing-List Modifications July 2023 Content-footer: i=2, b=79, e=124 From: district@mailinglist.example.com DKIM-Signature: d=mailinglist.example.com Subject: [district list] [school list] A really big announcement Content-footer: i=1, b=34, e=78 Prior-From: i=2,l=9, school@mailinglist.example.com Prior-DKIM-Signature: i=2,l=8, d=mailinglist.example.com Prior-Subject: i=2,l=7, [school list] A really big announcement Prior-From: i=1,l=5, john.doe@example.com Prior-DKIM-Signature: i=1,l=4, d=example.com Prior-Subject: i=1,l=3, A really big announcement It's Jane Doe's birthday tomorrow! ============ This is the school mailing-list. ============ This is the district mailing-list. The receiver sees the above message on inbound delivery, and attempts to reverse it. After applying the reverse procedure on the newest ARC set i=2, the reversed message looks like: Content-footer: i=1, b=34, e=79 From: school@mailinglist.example.com DKIM-Signature: d=mailinglist.example.com Subject: [school list] A really big announcement Prior-From: i=1,l=5, john.doe@example.com Prior-DKIM-Signature: i=1,l=4, d=example.com Prior-Subject: i=1,l=3, A really big announcement It's Jane Doe's birthday tomorrow! ============ This is the school mailing-list. After applying the reverse procedure on the second newest ARC set i=1, the reversed message looks like: From: john.doe@example.com DKIM-Signature: d=example.com Subject: A really big announcement It's Jane Doe's birthday tomorrow! Chuang Expires 11 January 2024 [Page 9] Internet-Draft Mailing-List Modifications July 2023 The resulting reversed headers and message body DKIM-Signature verifies, and the REVERSE passing result is published in the ARC- Authentication-Result: ARC-Authentication-Result: i=3; mx.example.com; reverse=pass; dara=pass Content-footer: i=2, b=79, e=124 From: district@mailinglist.example.com DKIM-Signature: d=mailinglist.example.com Subject: [district list] [school list] A really big announcement Content-footer: i=1, b=34, e=78 Prior-From: i=2,l=9, school@mailinglist.example.com Prior-DKIM-Signature: i=2,l=8, d=mailinglist.example.com Prior-Subject: i=2,l=7, [school list] A really big announcement Prior-From: i=1,l=5, john.doe@example.com Prior-DKIM-Signature: i=1,l=4, d=example.com Prior-Subject: i=1,l=3, A really big announcement It's Jane Doe's birthday tomorrow! ============ This is the school mailing-list. ============ This is the district mailing-list. 4. IANA Considerations There are no requests at this time. 5. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Weihaw Chuang Google, Inc. Email: weihaw@google.com Chuang Expires 11 January 2024 [Page 10]