]> DKIM Access Control and Differential Changes
steffen@sdaoden.eu
 General Internet Engineering Task Force DKIM 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.
Introduction Public-key cryptography is used for secure transactions on many levels, and in many protocols. For example, transport layer security TLS provides encrypted data exchange. It is omnipresent, desired where optional, even enforced by standard means, and newer IETF transports, like QUIC, 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, 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 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 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.
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 when, and only when, they appear in all capitals, as shown here.
DKIMACDC The DKIM, extension Access Control and Differential Changes places DKIM signatures in a random-accessible ordered sequence which' state correlate. It adds reversible data difference tracking, and as such supports cryptographical content verification of 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.) On mutual agreement with receiver domains cryptographically verifiable precautions are taken to ensure that only initially addressed "mailbox local-part"s can be used as SMTP RCPT addressees. The DKIM, 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 reply code 550 is to be used; with enhanced SMTP status codes 5.5.4 MUST be used.
[DISCUSSION: ] 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 (, section 2.5), in turn improving the mentioned "detectable conditions".
Flag description is normative. ABNF: Forward it would be acdc = %x61 %x63 %x64 %x63 [FWS] = [FWS] sequence ":" 1*(flag) ":" [ADDRESS ":" ID ":" ] (or so) where ADDRESS would be an all-ASCII-only local-part@domain to sent an entire rejected message as a rfc822 attachment to, with a to-be-defined Subject:, like "DKIMACDC rejection: ID" and the ID would be some transparent value in base64 character set; without ADDRESS the return-path would be used; IE: that is: last hop failure only!? ADDRESS could also come from DKIMACDC DNS record of the failed hop.] ]]>
D
The message was modified at this hop, DKIMACDC differential changes were generated, and are stored in a DKIM-Diff-sequence header. (Not in combination with the O flag.)
O
The message originated at this hop, the signature refers to the first address of the From header. Only in signatures with sequence number 1. 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 headers To and Cc only contain a single addressee with the local part postmaster, and if the same "postmaster" is addressed as a SMTP 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. [DISCUSSION: there are lots of automatic-bcc configurations around, so multiple RCPT TO must be supported, the question is the limit; at least, that is. One additional address is deemed ok for now as local administrators can be expected to create aliases etc shall they need more than this single addition: allowing more addresses seems more problematic than this rather minor administrative effort; yes, it is effort.]
R
Reputation check to collect organizational trust (, 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. [DISCUSSION: i would love to see the following, it should be possible by mail filters to place an additional header before the message is bounced?? With F/Forward however it is useless as it gets send there anyway.] In conjunction with flag X an invalid chain entry in the chain of valid DKIMACDC signatures was detected, and the sequence number of the failing signature has to be added to the acdc= tag after a separating colon. (The "failing signature" after differential recreation of a former message state is the signature which stored the wrong differential data.) Only after DKIM signature creation the resulting message has to be rejected. [DISCUSSION: this then needs an ABNF addition] ] Only in signatures with sequence numbers greater than 1, and without the Z or z flags (in earlier signatures). [DISCUSSION: 2 b easy, only DKIMACDC awareness is covered by this. Z flag would be doable; then message rejection .. what?? Talk on how often etc this can / should be done, DOS attack etc.]
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, [DISCUSSION: z only if From really failed?? That is, *DO* verify more??] 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. [DISCUSSION: should talk on how many and which DKIM signatures should be tried for verification in that situation] 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.)
Invalid flag combinations and flag misuse MUST result in rejection with SMTP reply code 550; if enhanced status codes are used, 5.5.4 MUST be used. (This includes the P flag upon incorrect use.)
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.
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 message does not include Bcc headers, DKIM does not cover the actual real set of message receivers. (Effectively any malicious party can use the validatable message with any possible SMTP 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. Access control addresses replay. When signing as an originator (sequence number 1, 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. [DISCUSSION: _dkimacdc.DOMAIN record. which content? maybe really the "default DKIM key to be exepcted", then MUST ADAED25519 :), but surely a version number With F/Forward flag, an all-ASCII (non-quoted!) email address. CNAME MUST be allowed and followed! RFC 6376 says This document defines a single binding, using DNS TXT RRs to distribute the keys. Other bindings may be defined in the future.] For any domain that announces DKIMACDC support the completely prepared message, including the readily prepared DKIM-Signature, is forged a dedicated DKIM-Access-Control header is created and prepended, and the resulting domain-specific message is sent to the logical receiver subset. [DISCUSSION: there are two possibilities to do this: 1. like here, DKIM-Signature only implicitly signals presence of ANY D-A-C header, and only the D-A-C header itself is per-receiver-domain: this has the problem that the receiving domain "blindly" assumes/expects there is one D-A-C header for itself, and fails if not. 2. both, DKIM-Signature(s) and D-A-C are created per-receiver-domain: (much) more expensive, but D-S can flag presence of D-A-C exactly; this also reveals the info itself like so to "the world", though. The draft uses 1. because except for a short transition time the difference of 1. and 2. is about "how an obvious attack shows up": either the D-A-C header was maliciously removed, or the DNS was filtered so it was never created, it does not truly make a difference as both simply cause rejection. IE: *is* it worthwhile to be able to differentiate these two by incurring a much larger processing cost?] A DKIMACDC-enabled and -announcing receiver domain that receives a DKIMACDC message MUST reject messages which do not contain a DKIM-Access-Control header dedicated to itself with SMTP reply code 550; if enhanced status codes 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. (It SHOULD, however, not perform the rejection until some time, for example the time-to-live TTL of "its DNS resource records" RR, and also see DNS negative caching, after starting to announce DKIMACDC.) [DISCUSSION: as above, all this only applies in the variant which does not use per-receiver-domain D-S headers.] Senders MAY use Delivery Status Notifications to fine-tune the resulting behaviour. [DISCUSSION: yeah, mention it explicitly.]
The DKIM-Access-Control header field 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 RCPT TO: was indeed addressed by the message sender; if the header included and the SMTP list do not match, the message MUST be rejected with SMTP reply code 550; if enhanced status codes 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, [DISCUSSION: the next is no good as if it remains the sender can use it to verify to have been the originator (reputation?) We could have this F/Forward "ID", but only for rfc822 stuff?] and it MUST NOT be part of a rejected message. Multiple instances of this header always indicate an error and MUST result in message rejection with SMTP reply code 550; if enhanced status codes are used, 5.5.4 MUST be used. [DISCUSSION: a-c domain / RCPT-TO mismatch??] The header is created by, and signed with the DKIM key of the domain that created the DKIM signature with sequence number 1, and with the same hash algorithm. The header value consists of a semicolon-separated list of entries, first the destination domain-name, then in unspecified order the local-parts of addressed RCPTs [DISCUSSION: properly re-quoted? there are bogus/ugly quote forms on the fly!!], followed by the signature. It is created exactly like the DKIM-Signature field in that it is readily prepared and thereafter signed.
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-delivery troubles. 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-sequence header has to be created, and the D indicator flag has to be added to the acdc= tag. All existing DKIM-Diff-sequence 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. 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 vanish upon policy change.
The DKIM-Diff-sequence header field To generate differential changes the DKIM "relaxed" normalized header and body content is stored, separated by an empty (normalized) line, and is passed alongside the equally normalized version present before the modifications took place through the BSDiff algorithm, as below. [DISCUSSION: the header order should be normalized to reduce diff size. Maybe: ASCII-alpha-sort header names at first. All new headers should .. ..be pre/appended as a block ..stay integrated in that sorted order.] For non-integrated systems like mail filters the DKIM-Store header can for example 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. In general all headers covered by the DKIM-Signature MUST be included, as MUST be all MIME related headers, regardless of their normal inclusion in the DKIM-Signature. (The MIME headers SHOULD be regulary included in DKIM signatures to remove the otherwise existing attack surface against the MIME structure through maliciously injected headers and body content.) [DISCUSSION: that is merde. Here should be a MUST list of practically all header fields which are used by the email system, except for trace headers: reply-to author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references list-id list-help list-subscribe list-unsubscribe list-post list-owner list-archive mime-version content-type content-transfer-encoding content-disposition content-id content-description message-id mail-followup-to openpgp And then: really all with RFC references?? The problem is also caused by DKIM configurations as seen in the wild, which often cover only a minimal set of fields! ]
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: it was decoupled from the fixed I/O and compression machinery, the memory allocator is hookable, and the integer type width is (again) a build time option; in addition the sliding window is run-time configurable. There is a freely usable (BSD 2-clause/ISC and MIT licenses) plug-and-play ISO C99 and perl implementation available (), which includes further references on the algorithm. DKIMACDC uses the 32-bit variant sufficient for email, which almost halves memory requirements compared to 64-bit, and also produces smaller difference control data. The resulting binary difference is then ZLIB compressed and encoded with BASE64 for inclusion in the DKIM-Diff-sequence header.
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, 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 inline text plus signature couple would likely fail to verify because of DKIM normalization (also dependent upon the original MIME par 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 could ideally say where. 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.
IANA Considerations This memo includes no request to IANA.
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 (, section 2.5) that aids decision making to increase processing performance and decrease energy consumption. If superfluous protocols vanish this potentiates.
References Normative References Informative References
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. 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. 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. 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.
Acknowledgements This document contains a citation of Dave Crocker. Thanks to, in the order of appearance, Jesse Thompson, Richard Clayton, and Douglas Foster. 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.