Internet Engineering Task Force S. Nurpmeso, Ed.
Internet-Draft 3 February 2025
Updates: 6376 (if approved)
Intended status: Informational
Expires: 7 August 2025
DKIM Access Control and Differential Changes
draft-nurpmeso-dkim-access-control-diff-changes-02
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 7 August 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 7 August 2025 [Page 1]
Internet-Draft DKIM Access Control and Differential Cha February 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 field . . . . . . . . . . . . . . . . . 7
4. Access Control . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. The DKIM-Access-Control header field . . . . . . . . . . 8
4.2. The _dkimacdc.DOMAIN DNS TXT RR . . . . . . . . . . . . . 9
5. Differential Changes . . . . . . . . . . . . . . . . . . . . 9
5.1. The DKIM-Diff header field . . . . . . . . . . . . . . . 10
5.2. The BSDiff differential algorithm . . . . . . . . . . . . 11
5.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Further DKIM Updates . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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
Nurpmeso Expires 7 August 2025 [Page 2]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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.
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.
* 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,
Nurpmeso Expires 7 August 2025 [Page 3]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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]:
Nurpmeso Expires 7 August 2025 [Page 4]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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
Nurpmeso Expires 7 August 2025 [Page 5]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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
Nurpmeso Expires 7 August 2025 [Page 6]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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.
Nurpmeso Expires 7 August 2025 [Page 7]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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.
4.1. 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[RFC5321] RCPT TO was indeed addressed
by the message sender, which indeed is the one mentioned in MAIL
FROM; 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[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.
Nurpmeso Expires 7 August 2025 [Page 8]
Internet-Draft DKIM Access Control and Differential Cha February 2025
The syntax of this header is a semicolon separated list. It starts
with the sequence number of the DKIM-Signature to which it links,
which necessarily MUST have the O flag set, followed by the selector
value of the s= tag of the according DKIM-Signature; the actual
algorithm can be deduced from there. (As there may be multiple
signatures, multiple DKIM-Access-Control headers may be generated,
unless the _dkimacdc DNS entry hints a supported algorithm.)
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 the receiver domain. 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.
4.2. The _dkimacdc.DOMAIN DNS TXT RR
The format of this DNS resource record mirrors the syntax of
DKIM[RFC6376] section 3.5 on the DKIM-Signature header field, with
the exception that FWS separation is not allowed; supported are the
tags v= and a=, however, v= is optional, and none to multiple a= tags
MAY exist. The a= tag indicates that DKIM-Access-Control headers
SHOULD only be generated with that algorithm, and that an according
DKIM-Signature is the most desirable for this domain. 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.
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
Nurpmeso Expires 7 August 2025 [Page 9]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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.
5.1. The DKIM-Diff header field
The DKIM-Diff header field 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 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.
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
Nurpmeso Expires 7 August 2025 [Page 10]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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 alphabetically by name, and the formed
subgroups MUST be sorted byte-wise alphabetically by content. 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 Field[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: 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
(https://github.com/sdaoden/s-bsdipa), 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[RFC1950]
compressed and encoded with BASE64[RFC4648] for inclusion in the
DKIM-Diff header.
Nurpmeso Expires 7 August 2025 [Page 11]
Internet-Draft DKIM Access Control and Differential Cha February 2025
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.
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.
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.
Nurpmeso Expires 7 August 2025 [Page 12]
Internet-Draft DKIM Access Control and Differential Cha February 2025
8. References
8.1. Normative References
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[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,
<https://www.rfc-editor.org/info/rfc6376>.
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,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>.
[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,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, DOI 10.17487/RFC3461, January 2003,
<https://www.rfc-editor.org/info/rfc3461>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003,
<https://www.rfc-editor.org/info/rfc3463>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
Nurpmeso Expires 7 August 2025 [Page 13]
Internet-Draft DKIM Access Control and Differential Cha February 2025
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[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,
<https://www.rfc-editor.org/info/rfc5863>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9057] Crocker, D., "Email Author Header Field", RFC 9057,
DOI 10.17487/RFC9057, June 2021,
<https://www.rfc-editor.org/info/rfc9057>.
[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, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9369] Duke, M., "QUIC Version 2", RFC 9369,
DOI 10.17487/RFC9369, May 2023,
<https://www.rfc-editor.org/info/rfc9369>.
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.
Nurpmeso Expires 7 August 2025 [Page 14]
Internet-Draft DKIM Access Control and Differential Cha February 2025
* 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.
* 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.
Nurpmeso Expires 7 August 2025 [Page 15]
Internet-Draft DKIM Access Control and Differential Cha February 2025
Appendix B. Acknowledgements
This document contains a citation of Dave Crocker. Thanks to, in the
order of appearance, Jesse Thompson, Richard Clayton, and Douglas
Foster. 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 7 August 2025 [Page 16]