Network Working Group                                        B. Gondwana
Internet-Draft                                          Fastmail Pty Ltd
Obsoletes: 4686 (if approved)                                 R. Clayton
Intended status: Standards Track                                   Yahoo
Expires: 4 September 2025                                      W. Chuang
                                                                  Google
                                                            3 March 2025


 DKIM2 Why DKIM needs replacing, and what a replacement would look like
                   draft-gondwana-dkim2-motivation-02

Abstract

   This memo provides a rationale for replacing the existing email
   security mechanisms with a new mechanism based around a more strongly
   authenticated email delivery pathway, including an asynchronous
   return channel.

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 4 September 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Gondwana, et al.        Expires 4 September 2025                [Page 1]

Internet-Draft              DKIM2 Motivation                  March 2025


   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.  Background and motivations  . . . . . . . . . . . . . . . . .   2
   2.  Some properties that will be required to deliver on these
           goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  A single recipient per signature  . . . . . . . . . . . .   3
     2.2.  A chain of aligned DKIM2 signatures over SMTP from/to
           pairs . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  A signed bounce format, sent in reverse along the same
           path  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  A way to describe changes . . . . . . . . . . . . . . . .   5
     2.5.  Simplification of signed header list  . . . . . . . . . .   5
     2.6.  Security gateways . . . . . . . . . . . . . . . . . . . .   5
   3.  Goals ot be addressed by DKIM2  . . . . . . . . . . . . . . .   6
     3.1.  DKIM-replay . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Backscatter . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Other areas of interest . . . . . . . . . . . . . . . . . . .   7
     4.1.  Algorithmic dexterity . . . . . . . . . . . . . . . . . .   8
     4.2.  Reducing crypto-calculations  . . . . . . . . . . . . . .   8
   5.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Changes from Earlier Versions  . . . . . . . . . . .   9
     A.1.  draft-gondwana-dkim2-motivation-02: . . . . . . . . . . .   9
     A.2.  draft-gondwana-dkim2-motivation-01: . . . . . . . . . . .   9
     A.3.  draft-gondwana-dkim2-motivation-00: . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Background and motivations

   In 2007, [RFC4871] (Domain Key Identified Mail / DKIM) was published,
   outlining a mechanism for a domain to sign email in a way that
   recipients could ensure that the email had come from an entity
   possessing the secret key matching a public key published in the DNS
   by the source domain.  For clarity in this document we call this
   established scheme "DKIM1".

   [RFC4871] has been updated and extended many times since then, and a
   large amount of operational experience has been gained using it.



Gondwana, et al.        Expires 4 September 2025                [Page 2]

Internet-Draft              DKIM2 Motivation                  March 2025


   There are a number of things beyond authenticating email that would
   be useful for mail system operators, particularly when it travels
   through multiple hops.  There have been other attempts to solve some
   of these problems, e.g. [RFC8617] (Authenticated Received Chain /
   ARC), however they have not achieved the same level of widespread use
   as DKIM1.

   This document proposes solving these related problems in a holistic
   way, by having every hop in a forwarding chain responsible for:

   1.  verifying the path that messages have taken to get to it,
       including by being able to reverse modifications or by asserting
       that it trusts the previous hop unconditionally.

   2.  declaring (under protection of its own signature) where the
       message is being sent to next.

   3.  promising that it will pass control messages (including bounces,
       abuse reports and delivery notifications) back to the previous
       hop for a reasonable time.

   There is no way to add these properties to existing DKIM1 in a way
   which is both backwards and forwards compatible, so any new
   specification will need new headers so that it not mis-interpreted by
   DKIM1 verifiers which are unaware of the new specfication.

2.  Some properties that will be required to deliver on these goals

2.1.  A single recipient per signature

   By only allowing precisely one destination address per DKIM2-signed
   email, and encoding that address in the signature, messages will be
   unable to be replayed to any other destination.  This allows
   recipients to confirm that they are the intended next hop for a
   message, and reject any message that is incorrectly formed.

   Even if a message is BCC'd, the copy of that message sent to the
   BCC'd recipient will have their own address in the DKIM2 signature,
   so replay to arbitrary addresses is no longer possible.

   During initial evaluation, there will be a period where receivers
   maintain a list of known dkim2-unaware forwarders and a longer term
   solution will be sought out; however we feel that the benefits of
   DKIM2 in identifying mail flow participants will help improve getting
   wanted email to their recipients, thereby driving adoption.






Gondwana, et al.        Expires 4 September 2025                [Page 3]

Internet-Draft              DKIM2 Motivation                  March 2025


2.2.  A chain of aligned DKIM2 signatures over SMTP from/to pairs

   If the recipient wishes to forward the message on to another address,
   it must apply its own DKIM2 header, signed by a key which is aligned
   to the domain of the recipient address in the previous DKIM2 header,
   and with a bounce address which is in the same domain.

   Both of the above requirements mean that every SMTP transaction for
   DKIM2 messages will, by necessity, have only a single recipient.  Any
   email to multiple people, alias that expands to multiple addresses,
   or mailing list, will create a different next-hop signature for each
   distinct destination address.

   The end result is, like ARC, a chain of domains which have handled
   the message; however unlike ARC, this chain MUST be fully linked in
   both directions, with every sending address aligning to the recipient
   address of the previous DKIM2 header.

2.3.  A signed bounce format, sent in reverse along the same path

   In DKIM2, DSNs are passed back along the same path.  This solves the
   issue with Email Service Providers (ESPs, entities that specialise in
   sending email on behalf of others) wanting error reports.  The ESP
   will see the DSN and, depending on contractual arrangements, may be
   able to avoid passing this message any further back along the chain.

   Since the DSN messages always go back up the DKIM2 chain, any hop can
   strip off the higher number (i=) records; including the sender and
   recipient addresses for them, and create a bounce as if the forwarder
   itself was doing the rejection.  As asynchronous bounces will be
   common in DKIM2, this is indistinguishable to the sender, allowing
   privacy-preserving forwarders to seamlessly operate.

   Passing bounces back along the outgoing path also allows mailing
   lists to take responsibility for the event and not bother the person
   who sent a message to the list.

   Provided that an email is correctly signed when received, it can be
   rejected at a later point in time.  The DSN will be sent to the
   immediately preceding intermediary.  Since the bounce travels back
   along the (fully authenticated) incoming path it cannot be sent to an
   uninvolved third party.









Gondwana, et al.        Expires 4 September 2025                [Page 4]

Internet-Draft              DKIM2 Motivation                  March 2025


2.4.  A way to describe changes

   DKIM2 will define an algebra for describing how to reverse any
   changes to create the prior binary data, by inspecting the diff
   between the two versions, recipients will be able to see who injected
   bad content.

   Mailing lists (or alumni forwarders etc.) that alter the Subject
   header field (or other [RFC5322] headers) will record the previous
   header field contents.  This is easy to undo for checking purposes.

   Mailing lists that add text (either to a simple email body or one or
   more MIME parts within the body) will record details of the text they
   have added.  This text can then be removed when checking earlier
   signatures.

   We expect an "algebra" describing changes to be in a stand-alone
   document.

2.5.  Simplification of signed header list

   While this part is not strictly necessary to achieve the goals above,
   some headers must be signed to get the guarantees, so rather than say
   that certain headers must be listed, DKIM2 will specify a fixed set
   of always-signed headers in accordance with now well-established best
   practice (and insist they are unique) so there will be no need to
   list what is signed in the common case.

   However, some exotic headers may need to be signed for unusual or
   future use-cases.  DKIM2 will still allow for extended headers.

   As the modification algebra allows for reversing changes to headers,
   it will not be necessary to oversign as any "extra" headers matching
   a signature must be either removed by the modification algebra, or
   break the signature.

   Any future hop must continue to sign any headers that were signed by
   previous hops, even if they removed the header via modification
   algebra they needs to sign the lack of it, so that modifications can
   be correctly checked.

2.6.  Security gateways

   There are some types of alteration, for example by security gateways,
   that may be impractical to describe in a cost-effective manner.






Gondwana, et al.        Expires 4 September 2025                [Page 5]

Internet-Draft              DKIM2 Motivation                  March 2025


   We would expect that outgoing gateways that may be adding disclaimers
   or rewriting internal identifiers would be provided with appropriate
   signing keys so that they could be the "first hop" as far as the rest
   of the email handling chain is concerned.

   Incoming security gateways may be making substantial changes.
   Typically they will remove problematic types of attachment and
   rewrite URLs to use "interstitials".  Since this type of
   functionality is generally provided on a contracted basis further
   intermediaries will be fully aware of the presence of the security
   gateway and can be configured to implicitly trust that it has checked
   earlier signatures and found them to be correct.  Hence there is no
   need to be able to "undo" these changes.

3.  Goals ot be addressed by DKIM2

3.1.  DKIM-replay

   Because an email can currently be sent as "Bcc" such that there's no
   evidence in the message data of who the recipient is expected to be,
   it's possible to take a message that is correctly signed and replay
   it millions of times to different destination addresses as if they
   had been BCC'd.  This message can be resent at any time.

   DKIM2 headers will always have timestamps so that "old" signatures
   have no value.

   A possibility to be investigated during testing is a "singleton" flag
   to allow senders to specify that this is a message for a single
   recipient (e.g. for authentication codes for billing transactions)
   and should not be expanded by mailing lists.

   DKIM2 headers specify both "from" and "to" so that most opportunities
   to alter a message, re-sign it and replay it at scale will no longer
   be possible.  Since the "to" address is always encoded in the email,
   any email to multiple recipients must be exploded by the sender, and
   each copy signed separately with different headers.

   If the email is replayed (perhaps through a large system with many
   different customers) then if the email does not say that it has been
   duplicated then signatures can be assumed to be unique and hence
   simple caching (or Bloom filters) will identify replays.  If the
   email has been duplicated then recipients can assign a reputation to
   the entity that did the duplication (along with the expected number
   of duplicates that will arrive from that entity) and assess duplicate
   signatures on that basis.





Gondwana, et al.        Expires 4 September 2025                [Page 6]

Internet-Draft              DKIM2 Motivation                  March 2025


   If the email is altered before duplication then it is again the case
   that this will be apparent to the recipient who can develop a
   reputation system for the entity that did the modification and
   replay.

3.2.  Backscatter

   The problem of backscatter, delivery status notifications sent to
   innocent third parties who had their address forged as the source of
   a message, has caused email recipients to implement a variety of
   countermeasures:

   *  in-band scanning: performing detailed analysis of the email
      content before replying to the DATA phase of the SMTP transaction,
      allowing immediate rejection but consuming resources on both ends
      of the connection, and limiting the time that can be used for the
      analysis to avoid timeouts.

   *  greylisting: replying with a temporary failure code to untrusted
      senders, allowing time to decide if the sender is trustworthy
      enough, but also delaying mail for an indeterminate period.

   *  delivery to "Spam" or "Junk" mailboxes - in some jurisdictions
      it's not allowed to discard email that has been accepted, so
      providers must put the copy somewhere once they have accepted it,
      filling Junk mailboxes even if they're very sure it's bad.

   By requiring bounce addresses to aligned with the most recent
   signature domain, we can avoid backscatter, allowing recipients to
   always take the message, and later return a bounce.  This fulfils any
   legal obligation to inform the sender if the message isn't delivered,
   while also avoiding the timeout and greylisting re-connection issue
   that currently exists, so messages are spooled for less time on
   intermediates, and recipients can take their time to analyse
   messages; even delivering the message to a mailbox and then upon
   receiving further intelligence, undoing the delivery and generating a
   bounce.

   Privacy-preserving forwarding services will also see every bounce
   from any dkim2-supporting destination mailbox, allowing them to strip
   off the details of the further hop(s) and generate a bounce as if
   they had been the terminal node of the delivery and were just making
   a delayed decision.

4.  Other areas of interest






Gondwana, et al.        Expires 4 September 2025                [Page 7]

Internet-Draft              DKIM2 Motivation                  March 2025


4.1.  Algorithmic dexterity

   The final specification will require both RSA and elliptic curve be
   implemented for algorithmic agility.  However this document
   acknowledges the long standing lack of adoption of elliptic curve
   ,and elliptic curve support may not be needed for development.  The
   specifications will provide support for multiple algorithms.  If
   there is IETF consensus around a "post-quantum" scheme then that will
   also be included.

   Dexterity will become essential if advances in cryptanalysis cause a
   particular type of algorithm to become deprecated.  To allow a phased
   switch away from such an algorithm we will make provision for more
   than one signature to be present in a single DKIM2 header.  Systems
   capable of checking both signatures will require both to be correct.
   If only one signature is correct then email will be rejected with a
   clear message -- allowing interworking issues to be easily debugged.

4.2.  Reducing crypto-calculations

   Experience at large mailbox providers is that incoming messages can
   have large numbers of DKIM signatures all of which need to be
   checked.  For DKIM2, in the common case where email has not been
   altered by earlier hops, it will only be necessary to check the first
   DKIM2 signature, the one applied by the previous hop and, if
   "feedback" is to be provided, the signatures of any entities that
   have requested feedback.

   If DKIM-replay is felt to be an issue (and some providers will detect
   this by identifying non-unique signatures) then more DKIM2 headers
   may need to be processed to establish the veracity of an alleged
   forwarding path.  Additionally any attempt to do forensics or to
   assign reputation to intermediaries will require more signatures to
   be checked.

5.  Security

   TBA

6.  IANA Considerations

   TBA

7.  Normative References







Gondwana, et al.        Expires 4 September 2025                [Page 8]

Internet-Draft              DKIM2 Motivation                  March 2025


   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, DOI 10.17487/RFC4871, May 2007,
              <https://www.rfc-editor.org/rfc/rfc4871>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [RFC8617]  Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
              Kucherawy, Ed., "The Authenticated Received Chain (ARC)
              Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8617>.

Appendix A.  Changes from Earlier Versions

   [[This section to be removed by RFC Editor]]

A.1.  draft-gondwana-dkim2-motivation-02:

   *  changed section title because DKIM1/2 do not really interwork as
      such

   *  removed implementation details, this is the motivation doc

   *  significant rewrite based on feedback from mailing list

A.2.  draft-gondwana-dkim2-motivation-01:

   *  remove the z= parameter on the grounds that it adds too much
      complexity

   *  document that messages MUST NOT re-enter the DKIM2 world once the
      chain has been broken.

A.3.  draft-gondwana-dkim2-motivation-00:

   *  initial version

Authors' Addresses







Gondwana, et al.        Expires 4 September 2025                [Page 9]

Internet-Draft              DKIM2 Motivation                  March 2025


   Bron Gondwana
   Fastmail Pty Ltd
   Level 2, 114 William Street
   3000
   Australia
   Phone: +61 457 416 436
   Email: brong@fastmailteam.com


   Richard Clayton
   Yahoo
   Email: rclayton@yahooinc.com


   Wei Chuang
   Google
   Email: weihaw@google.com


































Gondwana, et al.        Expires 4 September 2025               [Page 10]