Skip to main content

Tolerating Mailing-List Modifications
draft-chuang-mailing-list-modifications-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Wei Chuang
Last updated 2023-07-10
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chuang-mailing-list-modifications-00
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:

   <header name>:<value including any whitespaces>

   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=<bottoms-up line count" are prepended to the header value.  Thus
   the conserved header is:

Prior-<header name>: i=<#>,l=<bottoms-up line count>,<value including any whitespaces>

   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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Author's Address

   Weihaw Chuang
   Google, Inc.
   Email: weihaw@google.com

Chuang                   Expires 11 January 2024               [Page 10]