Internet Engineering Task Force S. Nurpmeso, Ed. Internet-Draft 20 March 2025 Updates: 6376 (if approved) Intended status: Informational Expires: 21 September 2025 DKIM Access Control and Differential Changes draft-nurpmeso-dkim-access-control-diff-changes-04 Abstract This document specifies a bundle of DKIM (RFC 6376) extensions and adjustments. They do not hinder the currently distributed processing environment that includes DKIM, ARC, DMARC and SPF, and are as such backward compatible. Their aim is however to ultimately slim down the email environment that needs to be administrated and maintained, by establishing mutual agreements in between sender and receiver(s), verifiable through public-key cryptography, and let the SMTP protocol handle decisions solely based upon that. 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 21 September 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 Nurpmeso Expires 21 September 2025 [Page 1] Internet-Draft DKIM Access Control and Differential Cha March 2025 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. DKIMACDC . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The DKIM-Store header . . . . . . . . . . . . . . . . . . . . 8 4. Access Control . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. The DKIM-Access-Control header . . . . . . . . . . . . . 10 4.2. The _dkimacdc.DOMAIN DNS TXT RR . . . . . . . . . . . . . 11 5. Differential Changes . . . . . . . . . . . . . . . . . . . . 11 5.1. The DKIM-Diff header . . . . . . . . . . . . . . . . . . 12 5.2. The BSDiff differential algorithm . . . . . . . . . . . . 13 5.2.1. BSDiff adaption . . . . . . . . . . . . . . . . . . . 13 5.2.2. Patch content . . . . . . . . . . . . . . . . . . . . 15 5.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Further DKIM Updates . . . . . . . . . . . . . . . . 18 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Public-key cryptography is used for secure transactions on many levels, and in many protocols. For example, transport layer security TLS[RFC9325] provides encrypted data exchange. It is omnipresent, desired where optional, even enforced by standard means: newer IETF transports, like QUIC[RFC9369], may even exist only in conjunction with it. The usual public-key cryptography mode of operation is, that if no trust can be established, the operation is cancelled. It simply does not happen. DKIM[RFC6376], on the other hand, defines as one of its core details that "signature verification failure does not force rejection". Yet there is such a pressing need of email operators to be able to enforce policy, that a plethora of extensive accompanying standards surrounding SMTP[RFC5321] and DKIM were developed, among which are ARC, DMARC and SPF. Reality is that the complexity of email setup, of administrative effort, has massively increased in the last decade plus, so much that many small commercial and private operators have ceased to exist, or have turned away from providing their own Nurpmeso Expires 21 September 2025 [Page 2] Internet-Draft DKIM Access Control and Differential Cha March 2025 service. Reality is also that large parts of those which still exist do not follow-suit "so-called" IETF progress out of belief of improving the situation, but instead they wait until interoperability problems arise, especially with the giant email players, before minimally invasive solutions are searched for. These are usually found by searching the internet, often by doing copy and paste of shared configuration snippets. Some of the mentioned standards even introduce massive complications of decade old habits and usage patterns. For example, many universities and other "groupings" offer stable member email addresses, and then forward email to current, "real addresses". This is made impossible by SPF[RFC7208] if taken by the word (RECOMMENDET), which it often, but dependent upon a software implementation or configuration, is. Non-standardized solutions, like "Sender Rewriting Scheme" for the given example, are then developed, and implemented, by the sheer necessity to keep a grown infrastructure in a usable state. Often these solutions are imperfect. In any case they try to circumvent a defect of an IETF standard, in an onion-alike environment of standards that has no other desire, if one lets aside all those masses of "reporting" capabilities that IETF standards developed over the last years, than to provide reliable and trustworthy verification of the sender / receiver relationship and the communicated data. What this specification tries to achieve is to provide a path to lesser complexity, to easier maintenance and administration efforts, on the one hand. And on the other hand it tries to solve the issues which still exist, regardless of the sheer number of IETF standards invented to improve the situation. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. DKIMACDC The DKIM[RFC6376] extension Access Control and Differential Changes: * Places DKIM signatures in a random-accessible ordered sequence which' state correlate. Identical DKIM signatures generated at the same hop, but which differ in only the used algorithm, share, however, a sequence number. Nurpmeso Expires 21 September 2025 [Page 3] Internet-Draft DKIM Access Control and Differential Cha March 2025 * Adds reversible data difference tracking, and as such supports cryptographical content verification of (potentially) any intermediate message representation, up to the initial variant as sent by the originator. (Potentially allowing user interfaces to, also partially or in configurable dose, undo modifications that the email system introduced along the message path. For example, mailing-list specific mutations: it could show the original From address line, not the DKIM/DMARC mitigation caused mailing-list address; but see below. * Takes, on mutual agreement with receiver domains, cryptographically verifiable precautions to ensure that only initially addressed "mailbox local-part"s can be used as SMTP[RFC5321] RCPT TO addressees, as well as to ensure that the SMTP[RFC5321] MAIL FROM mailbox is identifieable; the latter avoids that receivers can be fooled by man-in-the-middle to send backscatter bounces to random addresses. * DKIMACDC allows for rather cheap and easy detection (and testing) of the highest numbered signature, which can be sufficient for intermediate hops given the DKIM paradigm that "a single successful verification is sufficient for validation". * With DKIMACDC certain "detectable conditions" allow for quick rejection in a broken chain of trust. * DKIMACDC allows for pretty certain collection of statistics of organizational trust ([RFC5863], section 2.5), in turn improving the mentioned "detectable conditions". The DKIM[RFC6376] extension Access Control and Differential Changes is announced by adding an acdc= tag to the DKIM-Signature. (For efficiency reasons it SHOULD be placed early, before tags like h=, bh= and b=, for example.) The tag starts with "sequence", a decimal number starting at 1, or incremented by 1 from the highest DKIMACDC sequence number encountered in the message; the maximum value is 999: if incrementing would result in overflow, the message MUST to be rejected; sequence holes MUST also cause rejection (but see below); in both cases SMTP[RFC5321] reply code 550 is to be used; with enhanced SMTP status codes[RFC3463] 5.5.4 MUST be used. | _Informative remark:_ 999 is both a constraint and a very high | limit, dependent upon which type of processing is actually | involved. In todays' DKIM use several signatures per actual hop | are not uncommon, also in the sense that per-hop processing | pipelines involve several processing steps that each create DKIM | signatures. Since DKIMACDC is meant as a transparent upgrade path | it seems unwise to introduce a limit too low thus. On the other Nurpmeso Expires 21 September 2025 [Page 4] Internet-Draft DKIM Access Control and Differential Cha March 2025 | hand a high limit creates a D(enial) O(f) S(ervice) attack | surface, but again, since most often only the highest numbered | signature needs to be verified, this seems acceptable. Flag description is normative. (Note the missing FWS separators around =.) ABNF[RFC5234]: acdc = %x61 %x63 %x64 %x63 = sequence ":" 1*(flag) ":" [id] ":" sequence = 1*3DIGIT; DIGIT from RFC 5234 flag = "A" / "a" / "D" / "E" / "O" / "P" / "R" / "V" / "v" / "X" / "x" / "Y" / "y" / "Z" / "z" id = *42(ALPHA / DIGIT / "+" / "-"); optional (bounce) identifier A Access control is active; DKIM-Access-Control header(s), as below, are included. Once set, necessarily in combination with the O flag, all future DKIMACDC signatures must copy it. (It may be removed by a signature which claims a new message origin by setting the O flag.) a Access control is not active. D The message was modified at this hop, DKIMACDC differential changes were generated, and are stored in a DKIM-Diff header. (Not in combination with the O flag, except if the sequence number is greater than 1.) The Y flag has to be set. E SMTP[RFC5321] envelope (MAIL FROM, RCPT TO) was modified. Necessarily only in combination with the O flag. The y flag has to be set. O This hop claims the message origin. This either means that the message originated at this hop, in which case the signature (usually, DKIM-typical) refers to the first address of the From header, and the sequence number is 1. It can also mean that an intermediate hop performed modifications, or for other reasons claims "ownership" of the message. For example, a mailing-list received a message, and is now re-distributing it to its members, changing the SMTP envelope accordingly (and setting E and y flags). At the time of this writing this usually comes in conjunction with From header munging for DMARC mitigation, and often more IMF modifications (for example appending a footer), which therefore results in the necessity for differential change production, and setting the D (and Y) flag(s). The SMTP envelope MAIL FROM is adjusted to refer to the domain that claims ownership etc. Any formerly present DKIM-Access-Control header was removed. Access control headers are only generated for messages with the O flag set. Nurpmeso Expires 21 September 2025 [Page 5] Internet-Draft DKIM Access Control and Differential Cha March 2025 P Postmaster mode. With this flag set the behaviour of DKIMACDC borders test mode in that rejections must not occur (due to DKIMACDC). This is to allow for a communication possibility window in a situation where messages would always be rejected, due to misconfigurations et cetera, and as such reflects SMTP[RFC5321] section 4.5.1 Minimum Implementation. (If, due to some failure, the sequence number would be excessed by such a message, the sequence increment shall not be performed, even if it makes the message "more invalid". Implementations necessarily count the number of DKIMACDC instances, and may imply an absolute maximum in order to avoid endless message wandering aka "loops" nonetheless.) If the sequence number will be 1 message recipients have to be inspected. If the IMF[RFC5322] headers To and Cc only contain a single addressee with the local part postmaster[RFC1123], and if the same "postmaster" is addressed as a SMTP[RFC5321] RCPT recipient, and if no more than two RCPT recipients exist in total, then the P flag has to be set. Once set, all future DKIMACDC signatures must copy it. (It may be removed by a signature which claims a new message origin by setting the O flag.) R Reputation check to collect organizational trust ([RFC5863], section 2.5) along the signature chain was performed. On top of the V flag this means that all differential changes have been applied, and all signatures along the chain have been verified, and the entire chain validated correctly. Only in signatures with sequence numbers greater than 1, and without the Z or z flags (in earlier signatures). V DKIMACDC signature verified successfully. This means that the signature with the highest sequence number has been verified correctly, that the sequence of DKIMACDC signatures is complete, and their flags make sense (in the sequence). In conjunction with the flag R even deeper inspection was performed. Only in signatures with sequence numbers greater than 1. v DKIM signature verified successfully. In signatures with sequence number 1, then missing the O flag, it means the message originated at a non-DKIMACDC-aware host, and normal DKIM processing was performed and succeeded. Unless DKIM processing succeeded for the DKIM signature which covered the messages' From header address, the Z flag must be set, otherwise the z flag. In messages with higher sequence numbers it comes alongside the X flag: necessarily the DKIMACDC chain was broken, and the message changed, by an intermediate non-DKIMACDC-aware hop. The z flag must be set. X DKIMACDC verification failed; however, the normal DKIM signature verification was performed, and succeeded. The z flag must be set. Nurpmeso Expires 21 September 2025 [Page 6] Internet-Draft DKIM Access Control and Differential Cha March 2025 x DKIM verification failed. In signatures with sequence number 1, then missing the O flag, it means the message originated at a non- DKIMACDC-aware host, and normal DKIM processing was performed and failed. The z flag must be set. In messages with higher sequence numbers it comes alongside the X flag: necessarily the DKIMACDC chain was broken, and the message changed, by an intermediate non- DKIMACDC-aware hop. The z flag must be set. Y The message has seen IMF[RFC5322] modifications: somewhere along the chain the original message data was modified. Once set, all future DKIMACDC signatures must copy it. y The message has seen SMTP[RFC5321] envelope modifications: somewhere along the chain the original envelope was modified. Once set, all future DKIMACDC signatures must copy it. Z Announces the DKIMACDC chain is incomplete. The message was processed by DKIMACDC unaware hops. However, the message verifies correctly and seems to have never been modified non-reversibly. Once set, all future DKIMACDC signatures must copy it, unless later downgraded to the z flag. z The message has seen non-reversible modifications, and cannot be cryptographically verified back to its origin. Once set, all future DKIMACDC signatures must copy it. If this flag is set DKIMACDC looses its decisive meaning and "degrades" to normal DKIM: no more differential data is generated, and messages are distributed further / accepted if just any DKIM(ACDC) signature verifies. (Software configuration MAY allow otherwise.) id The optional "bounce identifier" offers enough room to store Universally Unique IDentifiers[RFC9562]. It MAY be generated to help sending domains to uniquely identify messages within the DKIM t= and x= time delta, as well as to ensure that successively sent identical messages are not detected as the same. Receiving domains should not use this identifier due to the denial of service attack surface, regardless of collected organizational trust (see R flag). Unknown flags MUST be ignored. Invalid flag combinations and flag misuse MUST result in rejection with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. (This includes the P flag upon incorrect use.) Nurpmeso Expires 21 September 2025 [Page 7] Internet-Draft DKIM Access Control and Differential Cha March 2025 3. The DKIM-Store header The DKIM-Store header has no meaning in the email system. The sole purpose of mentioning it is to announce that it MUST be removed when messages enter and leave the email system. It could for example be temporarily created and used by non-integrated mail filter (milter) software to pass informational data in between the "ingress" and the "egress" processing side. To aid in software bugs and possible configuration errors this specification enforces removal of all occurrences. It is suggested to encrypt data passed around in this temporary header with a key internal to the "local" email processing system in order to achieve locality. 4. Access Control DKIM replay attacks have been reported, where messages with valid DKIM signatures were repeatedly sent to receivers not initially addressed by the sender. That is: because the sent IMF[RFC5322] message does not include Bcc headers, and, to be exact, because the actual SMTP[RFC5321] RCPT recipients are not included at all, DKIM does not cover the real set of message receivers: effectively any malicious party can use the validatable message with any possible SMTP recipient. Whereas DKIM x= signature validity expiration tags can (MUST with ACDC as below) be used, the stamina and forgiveness of SMTP, owed to the necessity to deliver messages to receivers in various conditions, requires an expiration timestamp that leaves plenty of time for malicious players to misuse messages with valid signatures. In addition the actual SMTP[RFC5321] MAIL FROM sender is not covered by DKIM: any intermediate hop can (use the validatable message and) cause bounces to any possible MAIL FROM (backscatter bounce). Access control addresses replay and backscatter bounces. When signing as an originator (O flag set), all distinct domain-names found within the list of intended SMTP RCPT addressees are collected. Thereafter the DKIMACDC state of all found domains is queried, by looking up their _dkimacdc DNS entry, as below. For any domain that announces DKIMACDC support the completely prepared message, including the readily prepared DKIM-Signature(s), is forged, the A flag is set, (a) dedicated DKIM-Access-Control header(s) is/are created and prepended, and the resulting domain-specific message is sent to the logical recipient subset. | _Informative remark:_ Dedicated DKIM-Signatures are necessary: if | the message is also sent to a domain which does not support | DKIMACDC, but which forwards the message to a domain which does, Nurpmeso Expires 21 September 2025 [Page 8] Internet-Draft DKIM Access Control and Differential Cha March 2025 | that destination would otherwise falsely assume the presence of | access control; To simplify per-receiver-domain message creation | the DKIM-Signature header(s) can be readily prepared except for | toggling the single flag byte a to A, and, of course, creation of | the cryptographic signature itself. To address replay attacks by man-in-the-middle the DKIM x= tag MUST be used, in order to allow receiver domains to manage a message identity cache. The maximum t= to x= delta MUST NOT be greater than 864000 seconds (ten days: to reach into the next working week). Example delta values for tag auto-generation may be the bounce defaults 432000 seconds (five days: used for example by the Mailman2 and mlmmj mailing-list managers and the postfix MTA), 345600 seconds (four days: OpenSMTPD MTA), 172800 seconds (two days: Exim MTA). DKIMACDC aware receivers must keep a cache of received message identities to address this kind of replay attack during delta validity. (The DKIM-Access-Control header's signature appears like a natural cache key source, but see below.) In order to keep things simple, and the cache a write-once data structure, DKIMACDC senders MUST NOT generate per-receiver-domain messages with more than the 100 recipients that SMTP[RFC5321] section 4.5.3.1.8 guarantees as a minimum: if more recipients need to be addressed on a single domain, multiple messages with recipient subsets must be generated: like this each message is "atomic", and it is ensured the recipients of the SMTP envelope are all included in the DKIMACDC access-control signature, and vice versa. SMTP MTAs of domains which announce DKIMACDC MUST conform to SMTP[RFC5321] (section 4.5.3.1.8). | _Informative remark:_ Implementations MAY offer configuration | options to specify other recipient limits. For example, it may | offer domain whitelist settings which can be used to bundle | domains with higher limits. Like this the much higher limits in | actual use (for example, the Exim MTA has a default limit of | 50000) can be utilized. // The _dkimacdc DNS entry *could* | announce a definitive limit of // whatever sort! | _Informative remark:_ Space constraints resulting from maintaining | an identity cache may be addressed by timing out entries by | minutes or hours not seconds, by partitioning the cache through | DKIM d= tag values, and by using a hash-attack proven message- | digest output instead of message (access-control signature) | content data for keys. To selectively garbage collect cache | entries on memory shortage, collected reputation (see R flag) may | be used. A DKIMACDC-enabled and -announcing domain that receives a message with a set A flag MUST reject the message unless it contains (a) DKIM-Access-Control header(s) dedicated to itself with SMTP reply Nurpmeso Expires 21 September 2025 [Page 9] Internet-Draft DKIM Access Control and Differential Cha March 2025 code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. It MUST also reject messages which fail the signature, condition and flag check verification of such a header with SMTP reply code 550; the enhanced status code MUST be 5.7.7. Senders MAY use Delivery Status Notifications[RFC3461] to fine-tune the resulting behaviour. 4.1. The DKIM-Access-Control header The presence of this header empowers the receiving domain to cryptographically verify that it is indeed the correct destination domain, and that any given SMTP[RFC5321] RCPT TO was indeed addressed by the message sender, which indeed is the one mentioned in MAIL FROM; if the header included does not contain a superset of the SMTP envelope list, the message MUST be rejected with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used; 5.7.7 instead if signature verification failed. This header is to be sent only as part of exclusive and dedicated message instances, as documented above, it MUST be removed by the destination domain as soon as possible; it MUST NOT be delivered by local delivery agents as part of the message, and it MUST NOT be part of a rejected message. Any instance of such a header that is not targeted to the destination domain indicates an error and MUST result in message rejection with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. The syntax of this header is a semicolon separated list. It starts with the sequence number of the DKIM-Signature to which it links. As there may be multiple DKIM signatures with the same sequence number, which differ only in the used algorithm, multiple DKIM-Access-Control headers may be generated; in any case the linked signature(s) necessarily MUST have the O flag set. The sequence number is followed by the selector value of the s= tag of the according DKIM- Signature; the actual algorithm can be deduced from there. The next field is reserved for later extension, it MUST be skipped over. (It may include the string "VERP" to indicate variable envelope return path addresses at some later time.) Thereafter follows the SMTP[RFC5321] MAIL FROM of the covered message, the receiver domain name which is addressed, followed by all SMTP RCPT TO local-parts of the receiver domain actually addressed by the message. The list is concluded with the cryptographic signature which has been generated on the DKIM "relaxed" normalized content of the DKIM-Access-Control header up to, and including, the semicolon that precedes the signature. _Warning:_ SMTP[RFC5321] address local-parts permit quoted-strings. Nurpmeso Expires 21 September 2025 [Page 10] Internet-Draft DKIM Access Control and Differential Cha March 2025 4.2. The _dkimacdc.DOMAIN DNS TXT RR | _Apologies._ We now come to the reason why this proposal does not | work in todays', totally distorted state of the email | infrastructure, including IETF's very own email system (ok: bug | tracker; not ok: other mailing-lists i know). The problem is that | DKIMv1 signatures may be consciously broken, or even removed | completely, (or renamed, for example, mailman2 may rename to X- | Mailman-Original-DKIM-Signature), along the path from the sender | to the receiver domain. This (also) depends on the DMARC state of | the sender etc. In any case this destroys DKIMACDC chains. This | is why i, somewhere, somewhen, claimed that the DNS RR of DMARC is | the sole use case for it i can think about: if, instead of | _dkimacdc, we would extend the DMARC RR to include things | necessary for ACDC, so that everybody who wants ACDC has to | actually provide a (necessarily =reject) DMARC DNS entry, then | things were different. The only other possibility would be to | create a new header field, say, DKIM2, because the infrastructure | does not know that yet. It could be absolutely identical to the | DKIM signature, though. The format of this DNS resource record mirrors the syntax of DKIM[RFC6376] section 3.5 on the DKIM-Signature header, with the exception that FWS separation is not allowed; supported are the tags v= and a= (other tags MUST be ignored), however, v= is optional, and none to multiple a= tags MAY exist. They indicate, in descending order, the most desirable algorithms for this domain, and that the domain prefers to receive DKIM-Access-Control (and DKIM-Signature, if applicable) headers of the best fit algorithm. This can avoid unnecessary signature instances of undesired algorithms in case a domain normally produces signatures with multiple algorithms: it is only a hint to reduce processing cost of senders, it has no meaning beside this. Senders MUST be capable to follow DNS CNAME chains when looking up this DNS RR. // It could or should or must announce a definitive recipient limit // of whatever sort! 5. Differential Changes DKIM signatures never were designed to work with the existing mailing-list infrastructure, which often tags message subjects and/or appends footers (headers are supposed to be more of a theoretical issue). With the advent of some supplementary standard which worked around the DKIM "signature verification failure does not force rejection" paradigm, the resulting DKIM signature verification failures started to cause non-deliveries. Mailing-list software adopted in that they started to rewrite the From header in order to avoid breakage of the sender's signature. Further standards were Nurpmeso Expires 21 September 2025 [Page 11] Internet-Draft DKIM Access Control and Differential Cha March 2025 developed that tried to bring back trust that was lost by those modifications initiated to avoid that the forced signature breakage caused message delivery breakage. This specification adds the creation of differential changes, which can be applied in reverse order of creation, and therefore be used to cryptographically verify all intermediate changes back to the original version as sent by the sender. Whenever a DKIMACDC enabled domain breaks a message signature, for example if a mailing-list tags the subject and adds a message footer, an according DKIM-Diff header has to be created, with flag changes as described above. All existing DKIM-Diff headers MUST be included in DKIMACDC enabled DKIM- Signatures. | _Informative remark:_ It follows that the "changes cause a new | message" paradigm of today's DKIM/DMARC usage stays intact. It is | deemed correct behaviour: _Note that a message sent to a mailing | list is addressed to a mailing list. It is not addressed to the | 'final' recipients. That additional addressing is done by the | mailing list, not the original author. This is a rather stark | demonstration that the intermediary has taken delivery and then | re-posted the message._ However, DKIMACDC allows for | cryptographically verifying the original message, and therefore | can overcome the trust problem incurred by those "correct" | changes, which of course break the DKIM signature of the original | message. | _Informative remark:_ Today many mailing-list instances re-encode | message data for policy reasons, needlessly: for example from some | 7-bit clean content-transfer-encoding to 8-bit, or anything into | base64 (as below). This policy usually causes enlargening of the | differential changes on at least the first level (which for one is | most often the only one involved, and second it depends on the | content of the original message). This negative impact can thus | easily vanish, upon policy change. 5.1. The DKIM-Diff header The DKIM-Diff header consists of a sequence number that links it with a DKIMACDC enabled DKIM-Signature header, followed by a semicolon, and the result of the BSDiff differential algorithm, as below. The input to this algorithm is the DKIM[RFC6376] "relaxed" normalized header and body content, separated by an empty (normalized) line, alongside the equally normalized version present before modifications took place. For non-integrated systems like mail filters for example the DKIM-Store header can be used to pass around the necessary data in between the ingress side that sees the original message, and the egress side which will dispatch the modified variant. Nurpmeso Expires 21 September 2025 [Page 12] Internet-Draft DKIM Access Control and Differential Cha March 2025 All headers covered by the DKIM-Signature MUST be included, as MUST be all MIME[RFC2045] related headers, regardless of their normal inclusion in the DKIM-Signature. (MIME related headers SHOULD be regulary included in DKIM signatures to avoid the otherwise existing attack surface against the MIME structure through maliciously injected headers and body content, but as a domain policy this is not in scope of this document.) All DKIMACDC-enabled DKIM-Signature headers MUST be included, as MUST be all DKIM-Diff ones. The headers MUST be sorted byte-wise by-value by name, and the formed subgroups MUST consist in the order defined by DKIM[RFC6376] section 5.4.2, Signatures Involving Multiple Instances of a Field. Other than that the advice of DKIM[RFC6376], section 5.4.1, on recommended signature content, still applies, but is hereby extended with the Author Header[RFC9057]. | _Informative remark:_ Since DKIMACDC is meant to (effectively) | incur the most minimal changes on the software side it does not | change the way how existing DKIM software verifies or creates | signatures in general. To integrate this extension into the | existing infrastructure it seems best to accept a small overhead | in the highly compressible BSDiff control data, instead of | introducing expensive prefiltering processing costs, for example, | by grouping "old" and "new" headers. Here also to note that in | mail filters the name and the content of headers fly by as | distinct data arrays, for example, so that the necessary control | structures for the sorting algorithm as above can be implemented | more efficiently than it sounds at first, and alongside the normal | processing. 5.2. The BSDiff differential algorithm Differences are generated with the BSDiff algorithm of Colin Percival, which has excellent characteristics. No reimplementation of the algorithm was necessary due to the Open Source licenses used in all its different parts, instead it was taken from the FreeBSD operating system source code, and slightly rearranged. There is a freely usable (BSD 2-clause, ISC and MIT licenses) plug-and-play ISO C99 and perl implementation available (https://github.com/sdaoden/ s-bsdipa), which includes further references on the algorithm. DKIMACDC uses a 32-bit adaption sufficient for email that almost halves memory requirements compared to 64-bit, and also produces smaller difference control data. The resulting binary difference is then ZLIB[RFC1950] compressed and encoded with BASE64[RFC4648] for inclusion in the DKIM-Diff header. 5.2.1. BSDiff adaption Nurpmeso Expires 21 September 2025 [Page 13] Internet-Draft DKIM Access Control and Differential Cha March 2025 * First of all: the string suffix sorting and difference creation approach of Colin Percival has been left unchanged. * The original had been fixated on 64-bit file sizes and content representation. The adaption supports (compile-time switching in between) 32-bit (and 64-bit). Using 32-bit almost halves memory constraints, and produces smaller patch control data. It is deemed sufficient for email purposes. (32-bit and 64-bit patches are not interchangeable.) * The "magic window of inspection" has been made configurable, from the fixed original value 8, which represents a perfect fit for compiler output. The adaption uses the default value 16, which is a very good fit for textual data. The value is, however, irrelevant on the patch application side. * In order to reduce memory usage during patch generation, the adaption uses a shared memory region for differential and extra data: the former is therefore stored in reversed order, top down. (This reduces memory usage by the size of the target data set.) * The adoption stores data in big endian (network; MSF; most significant byte first) instead of little endian (LSF; least significant byte first) byte order. * The original uses three separate bzip2 streams to serialize control, differential and extra data. The adaption separated patch generation from the I/O layer, which will therefore see the entire readily prepared patch data. DKIMACDC uses ZLIB[RFC1950] for patch compression. * The original header did not contain the size of the extra data, which was stored last, with its size implicitly extending to the end of the patch. The adaption includes the extra data size in the header, allowing more verification tests to be applied with only the header being readily parsed. This also enables the I/O layer to allocate perfectly sized memory with only the header data being available. * The adaption performs memory allocations through user provided callbacks. Nurpmeso Expires 21 September 2025 [Page 14] Internet-Draft DKIM Access Control and Differential Cha March 2025 5.2.2. Patch content Overall, the patch consists of the header, followed by the control data. Thereafter the two byte streams of differential data (in reverse order) and extra data conclude the patch. The header and the control data consist of 32-bit signed integers, stored in big endian byte order (as above). The control data is a stream of tuples of three values each, the first denoting the length of differential data to copy in 8-bit bytes, the second that of extra data. The last value denotes the number of 8-bit bytes to seek relatively in the data source after the copying has taken place: of all the values, only this one may be negative. The header consists of four values denoting the length of the control block in 8-bit bytes, the length of the difference data block, the length of the extra data block, concluded by the length of the original data source; The sum of the first three values must be one less than the maximum positive 32-bit signed integer. It follows that control data copy instructions also do not exceed this value. 5.3. Rationale Differences are included to allow DKIM verifiers to restore previous message content for cryptographical verification purposes. Whereas user interfaces may (and should) use them to offer differential visualization (after signature verification, and with the usual precautions necessary for displaying content), empowering users to make decisions on the trustworthiness of those intermediate stations which actually incurred message modifications, the restored message data is not meant to result in a usable message by itself. For example some embedded OpenPGP signature and text couple would likely fail to verify because of DKIM normalization (dependent upon the original MIME transfer encoding). This was deemed acceptable because of the purpose of including differential changes, and because a visualization of the DKIM covered message should still be sufficient to allow users making responsible decisions. Finally, the given example will likely verify as part of the complete received message, unless altered along the SMTP path: DKIMACDC can ideally say where (and exactly what, in an unbroken ACDC chain). User interfaces could for example use traffic light semantics that unfold on click to traffic light semantics of all stations that a message passed, which would visualize differences on a further click. They could build complex reputation statistics based upon DKIMACDC verification and perceived user hints. This could be used to restrict DKIMACDC verification, to reduce complete-chain-verification to random samples. Further possibilities could arise shall SMTP/DKIM/DKIMACDC remain as the only solution to email verification in the future. Nurpmeso Expires 21 September 2025 [Page 15] Internet-Draft DKIM Access Control and Differential Cha March 2025 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations Public-key cryptography is the safest approach to identification of counterparts and verification of data. This specification aims in making use of these attributes for the combined pair of SMTP and DKIM. It opens a door to reduction of email server maintenance and administration efforts, and to restoration of some email core aspects which got lost, or became a nuisance to use, over the last decade(s), like email forwarding and mailing-list usage. It may reduce implementation burden and complexity of the entire email infrastructure. It allows for building of organizational trust ([RFC5863], section 2.5) that aids in decision making, to increase processing performance and decrease energy consumption. If superfluous protocols vanish this effect potentiates. 8. References 8.1. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [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, . 8.2. Informative References [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . Nurpmeso Expires 21 September 2025 [Page 16] Internet-Draft DKIM Access Control and Differential Cha March 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, DOI 10.17487/RFC5863, May 2010, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9057] Crocker, D., "Email Author Header Field", RFC 9057, DOI 10.17487/RFC9057, June 2021, . Nurpmeso Expires 21 September 2025 [Page 17] Internet-Draft DKIM Access Control and Differential Cha March 2025 [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . [RFC9369] Duke, M., "QUIC Version 2", RFC 9369, DOI 10.17487/RFC9369, May 2023, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . Appendix A. Further DKIM Updates * This specification obsoletes the simple canonicalization type; It MUST NOT be used by software announcing DKIMACDC. _Rationale:_ in order to minimize processing cost in time and space for and of differential processing, being able to work on and with only one data representation is beneficial. The "extremely crude ASCII Art attacks" mentioned in DKIM[RFC6376] section 8.1 are considered to be a rather artificial attack vector. * This specification obsoletes the DKIM l= tag that restricts the number of DKIM covered bytes of the normalized message body. This tag MUST NOT be used by software announcing DKIMACDC support, and all the message body MUST always be used to create the body hash. _Rationale:_ l= has always been insufficient to deal with message changes caused by mailing-lists etc, but effectively includes the security risk than message parts that are not covered by the signature appear as "valid content" to users looking at a DKIM verified message. The DKIMACDC differential changes offer a better approach to deal with message changes, while completely covered message bodies ensure content validity. * This specification obsoletes the DKIM z= tag that was defined "for diagnostic use" to copy a freely defined set of headers and their values present during signature creation. This tag MUST NOT be used by software announcing DKIMACDC. _Rationale:_ the DKIMACDC differential changes provide access to the same information distinct from the DKIM-Signature header. Nurpmeso Expires 21 September 2025 [Page 18] Internet-Draft DKIM Access Control and Differential Cha March 2025 * For the q= tag this specification obsoletes the possible use of DKIM-Quoted-Printable for the optional x-sig-q-tag-args of possibly introduced future query types. _Rationale:_ shall ever a new type become standardized beside the dns/txt that is with DKIM from the very start, that standard can very well give meaning to a "hyphenated-word" proxy identifier without making use of byte values which would require encoding. * This specification obsoletes the DKIM key representation tag n= that was meant to include "notes that might be of interest to a human", "intended for use by administrators, not end users", and which "should be used sparingly". _Rationale:_ no use case has been encountered in the DNS, let alone serious such; if future non-space-constrained key providers other than DNS should ever exist and be used to distribute DKIM keys, it is likely that they support inclusion of strings via some method that need not be included in the DKIM key representation itself. * Because above changes remove all use cases for the "dkim-quoted- printable" encoding defined in RFC 6376 2.11, this specification obsoletes the DKIM-Quoted-Printable encoding. * This specification obsoletes the use of FWS in ag-spec. Second its use was never encountered by the author. But first of all MIME[RFC2045] introduced parameters in ABNF as parameter := attribute "=" value without FWS, and its presence complicates parsers and hinders parser code reuse. The acdc= tag ("parameter") is defined without FWS support. Appendix B. Acknowledgements This document contains a citation of Dave Crocker. Thanks to, in the order of appearance, Jesse Thompson, Richard Clayton for arguments against reliance on header stacks, and pro the numbering scheme, and especially for noticing the partial transaction replay attack problem, Douglas Foster, Michael Thomas for explicit man-in-the- middle replay addressing; Alessandro Vesely inspired the explicitness of the E flag. A big fat acknowledgment is due to Murray S. Kucherawy. Special thanks to Klaus Schulze, Manuel Goettsching, both also as Ash Ra Tempel, Laeuten der Seele, Laurent Garnier, as well as the Sleeping Environmental Bot broadcast. Author's Address Steffen Nurpmeso (editor) Email: steffen@sdaoden.eu Nurpmeso Expires 21 September 2025 [Page 19]