DKIM Access Control and Differential Changes

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.¶

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 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, 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.¶

2. DKIMACDC

The DKIM[RFC6376] extension Access Control and Differential Changes:¶

• places DKIM signatures in a random-accessible ordered sequence which' state correlate.¶
• 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. This, of course, is only necessary due to the reluctance of email implementations to support the Author Header Field[RFC9057].)¶
• 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.¶

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 hand a high limit creates a D(enial) O(f) S(ervice) attack surface. 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". (For example, no From header parsing might be necessary.) 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".¶

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" / "O" / "P" / "R" /
       "V" / "v" / "X" / "x" / "Z" / "z"
id = *20(ALPHA / DIGIT / "+" / "-"); optional bounce ID

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; however, 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.)¶

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. At the time of this writing this usually comes in conjunction with From header munging for DMARC mitigation, but also to notify message changes performed by the list. The sequence number is greater than one, the SMTP[RFC5321] 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.¶

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 usually messages would always be rejected, may it be due to misconfigurations, etc. (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 receivers 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 receiver, and if no more than two RCPT receivers exist in total, then the P flag has to be set. Once set, all future DKIMACDC signatures must copy it.¶

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.¶

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.¶

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.)¶

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.)¶

3. The DKIM-Store header field

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 makes it a MUST to remove 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 receivers 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[RFC5321] RCPT. Whereas DKIM x= signature validity expiration tags can be used, and their use is hereby encouraged as a SHOULD, 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 receiver 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, 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.¶

A DKIMACDC-enabled and -announcing receiver domain that receives a DKIMACDC message MUST reject messages which do not contain (a) DKIM-Access-Control header(s) dedicated to itself with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. It MUST also reject messages which fail the signature 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.¶

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 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, and the D indicator flag has to be added to the acdc= tag. 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.¶

8. References