Hello, and good morning.
To announce the likely last iteration of this draft.
Unfortunately it is impossible to submit it, maybe only right now,
i have no idea, so i'll attach it.
https://datatracker.ietf.org/doc/draft-nurpmeso-dkim-access-control-diff-changes/
- Typos, shorter "tags=" for DKIM-AC:, added "Example" section.
- New section "DKIM Vivid Adjustments" collects changes to vivid
parts of DKIM v1 from all over the document.
(Accompanying thus the trailing "Further DKIM Updates" that mostly
obsoletes some dead wood.)
- Elaborate on "R" flag.
- Talk on multiple signatures for V/X.
-- Added "A" flag alongside ("all existing signatures verified", 'in
single-signature cases the "A" flag MAY be omitted').
- The "superset only test" of "t="s given in a DKIM-AC: compared to actual
envelope recipients is now MUST not SHOULD.
- "Works out" Mitigations'25 (a bit).
- Adds a sections "Apologies":
By accepting this draft the IETF recognizes that certain
developments of the past two decades mutilated the existing
email infrastructure to the point where it stopped functioning.
Without malicious intent [.]
...
it is hereby tried to create a solid foundation for a better
future.
The engineers who designed DKIMv1 already seem to have had a
notion of the necessity to undo changes along the message path,
for being able to verify elder signatures that got invalid due to
message changes, yet, the actual DKIM RFC then only contained an
insufficient solution to the problem.
Over the years, when the need to apply more security policies
to the email flow arose, and instead of iterating the existing
incomplete solution of DKIM first, simple "stop!" condition
solutions like DMARC and SPF, or even cryptographical nonsense
solutions like ARC, became introduced.
All these new solutions resulted in the situation that the grown
email infrastructure of mailing-lists and "alias farms" stopped
working.
Now the time has come to recreate a functional email
infrastructure, by picking up the work that was, if only in
parts, already present in the original DKIM standard.
Let us combine it with David Wheeler's fundamental theorem
of software engineering, that "We can solve any problem by
introducing an extra level of indirection".
Let us ensure that, on the SMTP level, the data can flow
again, based upon hard cryptographic facts, on verifiable
message states. Regardless of message changes as are applied
for example by mailing-lists.
If only a domain places its own verifiable cryptographic seal.
And if then such a message enters the system, we can not only
verify the very state of the message that domain gave to us, but
also the state of the message as it was when that domain itself
was given the message, and that further on, all the way back to
the very domain where the message originated.
Verifiable with public key cryptography, the best that we have.
All the way back to the originator.
So let us revive that beautiful oak DKIM v1 that has grown for
almost two decades, that was implemented in different languages,
so many times, that is doing its work in tnis very moment,
millions of times. There is nothing to abandon. Instead, we
should trim that old standard a bit, cut off the dead wood that
turned out to be unused, and the incomplete, never really worked
out solutions it ships with.
Also in Germany we unfortunately loose century old craftsmanship,
but our media under public law has some TV series on old
craftsmanship[1], for example, how to build a light airplane[2].
But also, how to care for trees, how to trim them. The Limewood
trimmed in [3] was badly treated in the past, but, shown in the
last seconds of the episode, if carefully trimmed, you will not
even recognize it was hurt by someone!
With ACDC DKIM will learn how to undo message modifications
so that the signatures of elder message states can be
cryptographically verified, it will cryptographically protect the
SMTP envelope, protect against those replay attacks also already
seen by the developers of DKIMv1, against backscatter bounces.
And all that in a backward compatible fashion.
Existing DKIMv1 software, if only it honours the standard of
ignoring unknown tags, will continue to function.
Of course, certain aspects of ACDC itself will only function
properly if intermediates are updated to use it; message
modifications must be covered by it, otherwise there is nothing
downstream consumers could unroll.
This is only logical.
If the Mitigations'25 approach is taken, the full power of
David Wheeler's indirection can be taken advantage of.
Then, it is up to user interfaces to adapt, and restore
those parts of former message content which are desired.
For example, to visually restore a mitigated From: header field
of a mailing-list. Many MUAs already have commands that allow
defining certain addresses as mailing-lists, extending this
functionality seems a natural thing to do.
But, different to today, where those From: mitigations already
exist, but cannot be trusted, it becomes cryptographically
verifiable, users can be presented verified data.
Compare this fact alone to the current state of affairs, after
the IETF has introduced decades of policy enforcing standards,
some even making use of cryptography!
Today -- nothing.
Tomorrow -- cryptographically verified.
Ciao! from Germany (shall no discussion evolve).
Hasta la Victoria siempre!
[1]
https://www.ardmediathek.de/sendung/handwerkskunst/Y3JpZDovL3N3ci5kZS8yNTA4MjkzNg
[2]
https://www.ardmediathek.de/video/handwerkskunst/wie-man-ein-flugzeug-baut/swr/Y3JpZDovL3N3ci5kZS9hZXgvbzE4MjA3NDY
[3]
https://www.ardmediathek.de/video/handwerkskunst/wie-man-einen-baum-schneidet/swr/Y3JpZDovL3N3ci5kZS9hZXgvbzE5NTAzODI
P.S.: i thought about going to Madrid; i would have found myself
"worth" going there, by train or even motor, given the three
drafts of mine. Yet, and also, i have no(t enough) trustworthy
persons who can take my part in "maintaining" the over hundred
souls i take care of (and they, in return). And it was a very
conscious decision in the past, for present (and future) souls.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
Use of an external entity file is not recommended. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude";
category="info"
docName="draft-nurpmeso-dkim-access-control-diff-changes-07"
ipr="trust200902"
obsoletes=""
updates="6376"
submissionType="IETF"
xml:lang="en"
version="3">
<!--
[CHECK]
* category should be one of std, bcp, info, exp, historic
* ipr should be one of trust200902, noModificationTrust200902,
noDerivativesTrust200902, pre5378Trust200902
* updates can be an RFC number as NNNN
* obsoletes can be an RFC number as NNNN
-->
<front>
<title>DKIM Access Control and Differential Changes</title>
<seriesInfo name="Internet-Draft" value="draft-nurpmeso-dkim-access-control-diff-changes-07"/>
<author fullname="Steffen Nurpmeso" initials="S" role="editor" surname="Nurpmeso">
<address><email>[email protected]</email></address>
</author>
<date year="2025" month="07" day="20"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>DKIM</keyword>
<abstract><t>
This document specifies a
DKIM (RFC 6376)
extension that allows cryptographic verification of
SMTP (RFC 5321)
envelope data,
and of DKIM signatures prior to
IMF (RFC 5322)
message content changes along the message path,
addressing thus security glitches,
and offering a new world of email solutions that move complexity
away from lower network layers,
where problems cannot be solved,
complying with David Wheeler's fundamental theorem of software
engineering, that "We can solve any problem by introducing an
extra level of indirection".
It updates DKIM to obsolete certain aspects that reality has
proven to be superfluous, incomplete, or obsoleted.
It is the future of email for email of the future.
</t></abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>
DKIM<xref target="RFC6376"/>
was not designed to cover
SMTP<xref target="RFC5321"/>
envelope data, allowing replay of valid, verifiable messages
to an infinite set of recipients by malicious third parties,
undetectable by sender and recipients.
(To aid SMTP delivery to recipients in various conditions the
optional "x=" expiration tag timestamp must be chosen so far
in the future that malicious players have plenty of time to
misuse messages.)
</t><t>
Whereas
DKIM<xref target="RFC6376"/>
standardized rudimentary, incomplete approaches to undo
modifications of
IMF<xref target="RFC5322"/>
message content that happen along the message path,
the overall design was agreed in not to survive them
(compare, for example,
<xref target="RFC6377"/>).
The resulting paradigm of DKIM is
"as long as one signature can be verified cryptographically,
DKIM verification will succeed".
This is problematic as message content changes may be falsely
attributed to (the) address(es) in the IMF originator field(s).
(Later policy-enforcing standards effectively complicated the
situation, in that false attribution may now technically be
avoidable, but mitigations of practice like "user A via B" will
still be attributed to "A" by a human for one, and, in short,
anything is valid if one DKIM signature is.)
</t><t>
Potentially many DKIM signatures may exist in a message.
DKIM<xref target="RFC6376"/>
gives hints on how verification can be performed,
but, in practice, mitigations are applied in order to reduce
excessive and useless verifications on hops down the message
path: elder signatures are removed, or renamed, as changes
are performed on message content, for example, by mailing-lists.
An approach to avoid excessive network traffic and CPU work
during message verification mitigates careless configurations.
</t><t>
The presented ACDC extension addresses these and more issues,
backward and forward compatible, easy adoptable, and easy
integratable into the current, existing infrastucture.
</t>
<section>
<name>Conventions and Terminology</name>
<t>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 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
<t>
When in the below message "REJECT"ion is said,
implementations may choose to instead move messages into a
spam or quarantine state.
</t><t>
The term "FOSS" refers to Free and Open Source Software.
</t>
</section>
</section>
<section>
<name>DKIM Vivid Adjustments</name>
<t>
The adult, mature, and rock solid foundation of
DKIM<xref target="RFC6376"/>
is built upon.
But this document obsoletes certain unused / incomplete aspects,
and adjusts certain vivid parts of the DKIM core, as follows.
The full context of the changes will become clear as the remains
of this document unfold.
</t><ul><li><t>
The signature expiration tag "x=" is no longer optional.
It <bcp14>MUST</bcp14> be used within DKIM-Signature: header
fields to place a lifetime constraint when creating signatures.
</t><t>
The maximum "t=" to "x=" delta <bcp14>MUST NOT</bcp14> 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).
</t></li><li><t>
ACDC, as below, aware software is urged to "oversign" aka "seal"
aka sign fields that are not present at the time of signing, how
DKIM (section 3.5, "h=" tag description) calls it.
Modifications and/or additions of "regular" intermediates will
then be covered by their "regular" signature, and the differences
will be discoverable via ACDC.
</t></li><li><t>
The advice of DKIM section 5.4.1,
on recommended signature content,
still applies,
and IANA is asked to introduce a registry of further header fields
to be included in cryptographic signature protection.
This document hereby includes the
Author Header Field<xref target="RFC9057"/>
in both lists.
</t></li></ul>
</section>
<section>
<name>DKIM ACDC</name>
<t>
The
DKIM<xref target="RFC6376"/>
extension Access Control and Differential Changes:
</t><ul>
<li>
Places DKIM signatures in an ordered, numbered,
random-accessible 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.
With ACDC it can be, and usually is, sufficient to verify
only the cheaply detectable highest numbered signature.
</li><li>
Adds reversible data difference tracking,
and as such supports cryptographical content verification
of any (ACDC ware) intermediate message state,
up to the initial variant as sent by the originator.
</li><li>
Cryptographically protects the
SMTP<xref target="RFC5321"/>
envelope, that is,
<tt>RCPT TO</tt> addresses
as well as the
<tt>MAIL FROM</tt>
address.
Replay of valid messages to initially not addressed recipients,
as well as backscatter bounces to random addresses instead of
the originator, become detectable.
</li><li>
Allows cryptographically verifiable collection of statistics of
organizational trust (<xref target="RFC5863"/>, section 2.5)
along the entire message path.
</li><li>
Allows recognition of certain flagged conditions (along the
message path) only by looking at the highest numbered signature.
</li>
</ul><t>
The
DKIM<xref target="RFC6376"/>
extension Access Control and Differential Changes
is announced by adding an "acdc=" tag to the DKIM-Signature:
header field.
(For efficiency reasons it <bcp14>SHOULD</bcp14> be placed
early, before tags like "h=", "bh=" and "b=", for example.)
</t><t>
The tag starts with "sequence",
a decimal number starting at 1,
or incremented by 1 from the highest ACDC "sequence"
encountered in the message;
the maximum value is 999:
if incrementing would result in overflow,
the message <bcp14>MUST</bcp14> be rejected;
detected sequence holes <bcp14>MUST</bcp14> also cause
rejection (but see below);
in both cases
SMTP<xref target="RFC5321"/>
reply code 550 is to be used; with
enhanced SMTP status codes<xref target="RFC3463"/>
5.5.4 <bcp14>MUST</bcp14> be used.
</t><t>
Multiple DKIM-Signature: header fields with the same "sequence"
<bcp14>MAY</bcp14> be generated by a domain, in which
case each field <bcp14>MUST</bcp14> use a different "s="
selector and algorithm.
</t><t>
Flag description is normative.
(Note the missing <tt>FWS</tt> separators around <tt>=</tt>.)
ABNF<xref target="RFC5234"/>:
</t><sourcecode><![CDATA[
acdc = %x61 %x63 %x64 %x63 = sequence ":" 1*flag [ ":" id ]
sequence = 1*3DIGIT; DIGIT from RFC 5234
flag = "A" / "D" / "E" / "I" / "O" / "P" / "R" / "S" / "s" /
"V" / "v" / "X" / "x" / "Y" / "y" / "Z" / "z"
id = *42(ALPHA / DIGIT / "+" / "-"); optional (bounce) identifier
]]></sourcecode><dl>
<dt>A</dt><dd><t>
Alongside the "V" flag this means that all existing signatures
were verified.
</t></dd><dt>D</dt><dd><t>
The message was modified at this hop,
ACDC differential changes were generated,
and are stored in a DKIM-DC: header field.
</t><t>
The "Y" flag has to be set.
</t></dd><dt>E</dt><dd><t>
The
SMTP<xref target="RFC5321"/>
envelope (<tt>MAIL FROM</tt> and/or <tt>RCPT TO</tt>)
was modified.
A new "Access Control" (see there) evaluation has been performed.
</t><t>
The "O" flag has to be set if the <tt>MAIL FROM</tt> changed.
The "y" flag has to be set.
</t></dd><dt>I</dt><dd><t>
This DKIM-Signature: header field was generated at ingress.
The purpose of such a field is that its flags can be used
to query the verification state of the message, verifiably.
(Also see the "R", "S", "s", "V" and "v" flags.)
</t><t>
All signature instances with this flag set <bcp14>MUST</bcp14>
be removed when messages enter and leave the email system.
(First.)
</t></dd><dt>O</dt><dd><t>
This hop claims the message origin.
</t><t>
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 field,
and the "sequence" is 1.
</t><t>
It can also mean that the current hop was the, quoting
<xref target="RFC3461"/>,
<em>"final delivery for the [original] message"</em>,
that the message got a <em>"new envelope return address"</em>,
that is, the <tt>MAIL FROM</tt> of the SMTP envelope was changed.
In this case the "E" flag has to be set.
</t><t>
An "Access Control" (see there) evaluation has been performed.
</t></dd><dt>P</dt><dd><t>
Postmaster mode.
With this flag set the behavior of ACDC borders test
mode in that rejections must not occur (due to ACDC).
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<xref target="RFC5321"/>
section 4.5.1 Minimum Implementation.
</t><t>
If the "sequence" is 1,
message recipients have to be inspected.
If the
IMF<xref target="RFC5322"/>
header fields To: and Cc: only contain a single addressee with
the local part
postmaster<xref target="RFC1123"/>,
and if the same "postmaster" is addressed as a
SMTP<xref target="RFC5321"/>
<tt>RCPT TO</tt> recipient,
and if no more than two <tt>RCPT TO</tt> recipients exist in
total,
then the "P" flag has to be set.
</t><t>
Once set, all future ACDC signatures must copy it.
It <bcp14>MUST</bcp14>, however, be removed when in conjunction with
the "D" and/or "E" flags the according SMTP envelope conditions are
no longer satisfied.
</t></dd><dt>R</dt><dd><t>
Reputation check to collect
organizational trust (<xref target="RFC5863"/>, section 2.5)
along the signature chain was performed.
</t><t>
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.
</t><t>
Only in signatures with a "sequence" greater than 1,
and without the "Z" or "z" flag.
</t><blockquote>
<em>Informative remark:</em>
The presence of "R" reveals local state publically;
however, in a chain of trust this seems desirable even.
The use of organizational trust may for example mean to
perform full reputation checks more and more sparingly,
the higher the trust, falling back to only random checks.
</blockquote></dd><dt>S</dt><dd><t>
Only in conjunction with the "I" flag: upon ingress the
SPF<xref target="RFC7208"/>
state was successfully verified.
</t></dd><dt>s</dt><dd><t>
Only in conjunction with the "I" flag: upon ingress the
SPF<xref target="RFC7208"/>
verification failed.
</t></dd><dt>V</dt><dd><t>
ACDC signature verified successfully.
</t><t>
The signature with the highest "sequence" has been verified
correctly,
the sequence of ACDC signatures is complete,
and their flags make sense (in the sequence).
In conjunction with the flag "R" even deeper inspection was
performed.
</t><t>
If multiple signatures with the same highest "sequence" exist,
the verifier behavior is unspecified in that "V" signals
success: at least one signature was checked, and all tested
signatures verified successfully.
If all signatures were verified,
the "A" flag <bcp14>MUST</bcp14> be set;
in single-signature cases the "A" flag <bcp14>MAY</bcp14> be
omitted.
</t><t>
Only in signatures with a "sequence" greater than 1.
</t></dd><dt>v</dt><dd><t>
DKIM signature verified successfully.
</t><t>
In signatures with "sequence" 1,
then missing the "O" flag,
it means the message originated at a non ACDC aware host,
and normal DKIM processing was performed and succeeded.
Unless DKIM processing succeeded for the DKIM signature which
covered the messages' From: header field address,
the "Z" flag must be set, otherwise the "z" flag.
</t><t>
In messages with a higher "sequence" it comes alongside
the "X" flag: necessarily the ACDC chain was broken, and the
message changed, by an intermediate non ACDC aware hop.
The "z" flag must be set.
</t></dd><dt>X</dt><dd><t>
ACDC verification failed ("V" flag conditions not met);
however, the normal DKIM signature verification was performed,
and succeeded.
</t><t>
The "z" flag must be set.
</t></dd><dt>x</dt><dd><t>
DKIM verification failed.
</t><t>
In signatures with "sequence" 1,
then missing the "O" flag,
it means the message originated at a non ACDC aware host,
and normal DKIM processing was performed and failed.
The "z" flag must be set.
</t><t>
In messages with a higher "sequence" it comes alongside
the "X" flag: necessarily the ACDC chain was broken, and the
message changed, by an intermediate non ACDC aware hop.
The "z" flag must be set.
</t></dd><dt>Y</dt><dd><t>
The message has seen
IMF<xref target="RFC5322"/>
modifications:
somewhere along the chain the original message data was modified.
Once set, all future ACDC signatures must copy it.
</t></dd><dt>y</dt><dd><t>
The message has seen
SMTP<xref target="RFC5321"/>
envelope modifications:
somewhere along the chain the original envelope was modified.
Once set, all future ACDC signatures must copy it.
</t></dd><dt>Z</dt><dd><t>
Announces the ACDC chain is incomplete.
The message was processed by ACDC unaware hops.
However, the message verifies correctly and seems to have
never been modified non-reversibly.
Once set, all future ACDC signatures must copy it,
unless later downgraded to the "z" flag.
</t></dd><dt>z</dt><dd><t>
The message has seen non-reversible modifications,
and cannot be cryptographically verified back to its origin.
Once set, all future ACDC signatures must copy it.
</t><t>
If this flag is set ACDC looses its decisive meaning
and "degrades" to normal DKIM (except for access control):
no more differential data is generated,
and messages are distributed further / accepted if just any
signature verifies.
(Software configuration <bcp14>MAY</bcp14> allow otherwise.)
</t></dd><dt>"id"</dt><dd><t>
The optional "bounce identifier" offers enough room to store
Universally Unique IDentifiers<xref target="RFC9562"/>.
</t><t>
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 being the same.
</t><t>
Receiving domains <bcp14>SHOULD NOT</bcp14> use this identifier
due to the denial of service attack surface,
regardless of collected organizational trust (see "R" flag).
</t></dd>
</dl><t>
Unknown flags <bcp14>MUST</bcp14> be ignored.
Invalid flag combinations and flag misuse <bcp14>MUST</bcp14>
result in rejection with SMTP reply code 550; if
enhanced status codes<xref target="RFC3463"/>
are used, 5.5.4 <bcp14>MUST</bcp14> be used.
(This includes the "P" flag upon incorrect use.)
</t>
</section>
<section>
<name>The DKIM-Store header field</name>
<t>
The DKIM-Store header field has no meaning in the email system.
The sole purpose of mentioning it is to announce that it
<bcp14>MUST</bcp14> be removed when messages enter
and leave the email system.
</t><t>
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.
</t><blockquote>
<em>Informative remark:</em>
In order to achieve locality it is suggested to encrypt data
passed around in this temporary header field with a key internal
to the "local" email processing system.
</blockquote>
</section>
<section>
<name>Access Control</name>
<t>
SMTP<xref target="RFC5321"/>
delivers messages to individual domains.
With ACDC, when a SMTP envelope was created or changed,
all distinct domain-names found within the list of intended
SMTP <tt>RCPT TO</tt> addressees are collected,
as the message needs to be forged on this individual domain base:
ACDC will create DKIM-AC: header fields covering SMTP envelopes,
and include them as messages are sent to individual domains.
</t><t>
The domains _dkimacdc DNS entries, as below, are queried.
Any domain that announces ACDC support can be served by a single
message for all recipients (possible limits, as below, aside).
For other domains, to guarantee anonymity, it is necessary to
differentiate in between public recipients in the To: and Cc:
header fields, and private recipients in the Bcc: header field.
<em>Remarks:</em> quality-of-service: for simplicity messages
may always be forged on a single recipient base, individually.
</t><t>
In any case the completely prepared message,
including the readily prepared DKIM-Signature:(s), is forged,
(a) DKIM-AC: header field(s) is/are generated which cover(s)
the logical recipient subset,
and the resulting message is then sent.
</t><t>
ACDC aware recipient domains are expected to manage a message
DKIM-AC: identity cache to mitigate replay attacks.
(Hint: the DKIM-AC: signature seems like a natural cache
key source, see below.)
The now mandatory and constrained "x=" tag allows for finite
identity cache sizes.
</t><t>
To keep the identity cache a write-once data structure, ACDC
senders <bcp14>MUST NOT</bcp14> generate DKIM-AC: header fields
with more than half of the 100 recipients that
SMTP<xref target="RFC5321"/>
section 4.5.3.1.8 guarantees as a minimum,
unless a
DNSSEC<xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/>
protected, or otherwise known trustworthy,
_dkimacdc DNS entry announced a different limit.
</t><t>
If more recipients need to be addressed on a single domain,
multiple message forges with recipient subsets must be generated:
like this each message forge is "atomic",
and the DKIM-AC: header field covers all the SMTP envelope.
</t><t>
SMTP MTAs of domains which announce ACDC <bcp14>MUST</bcp14>
support at least half the minimum limit required by
SMTP<xref target="RFC5321"/>
(section 4.5.3.1.8).
</t><blockquote>
<em>Informative remark:</em>
Implementations <bcp14>MAY</bcp14> offer configuration options
to specify other (higher, lower) recipient limits.
Like this the much higher limits in actual use
(for example, the Exim MTA default is 50000)
can be utilized.
</blockquote><t>
An ACDC aware recipient domain that receives an "acdc=" tagged
message without a DKIM-AC: header field <bcp14>MUST</bcp14>
reject the message with SMTP reply code 550; if
enhanced status codes<xref target="RFC3463"/>
are used, 5.5.4 <bcp14>MUST</bcp14> be used.
</t><t>
It <bcp14>MUST</bcp14> likewise fail if the DKIM-AC: header field
does not cover the SMTP envelope data.
It <bcp14>MUST</bcp14> test for a superset of recipients,
and only fail if an envelope recipient is not included in the
DKIM-AC: header field.
</t><t>
It <bcp14>MUST</bcp14> reject messages which fail the signature
check of a DKIM-AC: or DKIM-Signature: header field, or the
condition and flag check verification, with SMTP reply code 550;
the enhanced status code <bcp14>MUST</bcp14> be 5.7.7.
</t><t>
(Senders <bcp14>MAY</bcp14> use
Delivery Status Notifications<xref target="RFC3461"/>
to fine-tune the resulting behavior.)
</t>
<section>
<name>The DKIM-AC header field</name>
<t>
The syntax of this header field is the usual semicolon
separated list of DKIM-style tags of unspecified order;
unknown tags <bcp14>MUST</bcp14> be ignored.
It is used to cryptographically link the SMTP envelope
to the sent IMF mail message.
</t><t>
The "sn=" tag is the linked DKIM-Signature: "sequence",
best placed early.
Multiple signatures with the same "sequence",
but different algorithms may exist,
and so may DKIM-AC: header fields.
</t><t>
The selector of the linked signature is given by the "s=" tag,
the used algorithm can be deduced from there.
</t><t>
The "f=" tag is the
SMTP<xref target="RFC5321"/>
<tt>MAIL FROM</tt>
of the covered message, the complete <tt>addr-spec</tt>.
</t><t>
The "d=" tag value is the recipient domain,
with one to multiple "t=" tag(s) for the <tt>local-part</tt>s
of <tt>RCPT TO</tt>s.
</t><blockquote>
<em>Warning:</em>
SMTP<xref target="RFC5321"/>
address local-parts permit <tt>quoted-string</tt>s!
</blockquote><t>
Mirroring DKIM-Signature: the tag list is concluded with the
"b=" tag that is the cryptographic signature data of the
DKIM-AC: header field.
However, the reassembled (see
DKIM<xref target="RFC6376"/>,
section 3.5) "b=" value of the linked DKIM-Signature: is
"virtually assigned", and included when creating the
cryptographic signature;
thereafter the "b=" tag is assigned its own value.
</t><t>
All instances of DKIM-AC: header fields <bcp14>MUST</bcp14>
be removed by ACDC aware software as soon as possible:
they <bcp14>MUST NOT</bcp14> be delivered by local delivery
agents as part of the message, and <bcp14>MUST NOT</bcp14>
be part of rejected messages.
</t><t>
However, if a domain is only an intermediate, which was
neither directly addressed nor which originated the mail,
and which does not modify the SMTP envelope either, then it
<bcp14>MUST NOT</bcp14> remove the "current" DKIM-AC: header
field, and it <bcp14>MUST NOT</bcp14> generate a new one.
</t>
</section>
<section>
<name>The _dkimacdc.DOMAIN DNS TXT RR</name>
<t>
The syntax of this DNS resource record is the usual semicolon
separated list of DKIM-style tags of unspecified order;
unknown tags <bcp14>MUST</bcp14> be ignored.
However, <tt>FWS</tt> separation of tag, equal sign, and value
is not allowed.
</t><t>
DNS CNAME chains <bcp14>MUST</bcp14> be followed when looking
up this DNS RR.
</t><t>
The optional tag "rl=" contains an unsigned integer that asserts
the guaranteed minimum number of recipients that may be used as
<tt>RCPT TO</tt>s in a single transaction;
it may be as small as 1.
0 is treated as 1.
</t><t>
The tags "v=" and "a=" mirror their
DKIM<xref target="RFC6376"/>
(sections 7.5 and 7.6) tags,
however, "v=" is optional,
and none to multiple "a=" tags <bcp14>MAY</bcp14> exist:
they indicate, in descending order, the most desirable
algorithms for this domain.
Senders <bcp14>SHOULD</bcp14> try to honour the first fit,
and exclusively so if the algorithm is a well established one.
(For example, at the time of this writing, only RSA-SHA256 meets
this requirement, ED25519-SHA256 does not.)
</t>
</section>
</section>
<section>
<name>Differential Changes</name>
<t>
Whenever an ACDC enabled domain detects during DKIM-Signature:
creation that the relaxed representation of a message was
modified along its flight from ingress to egress, for example,
when it was processed by a mailing-list which tagged the
subject and added a message footer, a DKIM-DC: header field
has to be created.
</t><blockquote>
<em>Informative remark:</em>
In an unbroken chain of ACDC signatures the DKIM-DC: covered
changes can be applied in reverse order of creation in order
to cryptographically verify all intermediate message states and
signatures, back to the original version as sent by the sender.
</blockquote>
<section>
<name>The DKIM-DC header field</name>
<t>
The syntax of this header field is the usual semicolon
separated list of DKIM-style tags of unspecified order;
unknown tags <bcp14>MUST</bcp14> be ignored.
</t><t>
The "sn=" tag is the linked DKIM-Signature: ACDC "sequence",
best placed early.
</t><t>
The "c=" tag identifies the compression method used for the
data in "h=" and/or "b="; the value "z" means
ZLIB<xref target="RFC1950"/>,
whereas "xz" means
<xref target="LZMA2"/>.
ZLIB <bcp14>MUST</bcp14> be supported by signers and verifiers,
LZMA2 <bcp14>MUST</bcp14> only be supported by verifiers.
(FOSS implementations of all compression types are available.)
</t><t>
The "h=" tag is used to store differential data for header
fields, "b=" that for body content.
Both tags are optional,
but at least one <bcp14>MUST</bcp14> exists in a valid DKIM-DC:
header field.
</t><t>
The differential data is the result of the BSDiff algorithm,
as below, compressed with the method given in "c=", then
BASE64<xref target="RFC4648"/>
encoded.
</t><blockquote>
<em>Informative remark:</em>
The higher cost of using
<xref target="LZMA2"/>
compression can be amortized by the lesser necessary I/O.
When using the
<xref target="BSDIPA"/>
implementation as below, inspecting its header data can aid
choosing an appropriate compression algorithm on the fly.
</blockquote><t>
All header fields in the registry of headers to be included in
cryptographic signature protection, as above, <bcp14>MUST</bcp14>
be included.
All header fields covered by the DKIM-Signature:
<bcp14>MUST</bcp14> be included,
as <bcp14>MUST</bcp14> be all
MIME<xref target="RFC2045"/>
related header fields,
regardless of their presence in the DKIM-Signature:.
All ACDC enabled DKIM-Signature:
and DKIM-DC: header fields <bcp14>MUST</bcp14> be included.
</t>
</section>
<section>
<name>The BSDiff differential algorithm</name>
<t>
The differential changes are created with the DKIM "relaxed"
normalized header field and body data, respectively, as seen
on egress, alongside the equally normalized data present
before modifications took place, that is, on ingress.
</t><t>
The header fields <bcp14>MUST</bcp14> be sorted byte-wise
(by numeric US-ASCII byte value) by-name, the formed subgroups
<bcp14>MUST</bcp14> remain in the header stack order defined by
DKIM<xref target="RFC6376"/>
section 5.4.2, Signatures Involving Multiple Instances of a Field.
</t><t>
The BSDiff algorithm of Colin Percival, which has excellent
characteristics (and sees broadest use for decades), is
then used to create a binary delta of the header or body lines.
</t><blockquote>
There is a FOSS
<xref target="BSDIPA"/>
plug-and-play ISO C99 and perl implementation available that
iterated the FreeBSD operating system implementation of BSDiff,
and includes further references on the algorithm.
</blockquote>
<section>
<name>BSDiff adaption</name>
<ul>
<li>
First of all: the string suffix sorting and difference
creation approach of Colin Percival has been left unchanged.
</li><li>
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 usage,
and produces smaller patch control data.
It is deemed sufficient for email purposes, and used.
(32-bit and 64-bit patches are not interchangeable.)
</li><li>
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.
(Reduces memory usage by the size of the target data set.)
</li><li>
The adoption stores data in big endian (network; MSF;
most significant byte first) instead of little endian (LSF;
least significant byte first) byte order.
</li><li>
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 sees the entire readily prepared patch data, as below.
</li><li>
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.
</li>
</ul>
</section>
<section>
<name>Patch content</name>
<t>
Overall, the patch consists of the header,
followed by the control data.
Thereafter the two byte (8-bit octet) streams of
differential data (in reverse order)
and extra data conclude the patch.
</t><t>
The header and the control data consist of 32-bit signed
integers, stored in big endian byte order (as above).
</t><t>
The header consists of four values denoting
the length of the control block in 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.
Control data copy instructions also do not exceed this value.
</t><t>
The control data is a stream of tuples of three values each,
the first denoting the length of differential data to copy in
bytes, the second that of extra data to copy;
the read positions within the differential and extra data move
by the same amount of bytes.
The last value denotes the number of bytes to seek relatively
in the data source after the copying (if any) has taken place:
of all the values, only this one may be negative.
</t>
</section>
</section>
<section>
<name>Rationale</name>
<t>
Differences are included to allow DKIM verifiers to restore
previous message content for the purpose of cryptographically
verifying elder DKIM-Signature: header fields.
</t><t>
This for example allows for collecting trustworthy statistics of
organizational trust (<xref target="RFC5863"/>, section 2.5).
Or user interfaces may visually restore an initial From: header
field when messages come from a known mailing-list.
</t><t>
For example, user interfaces could use traffic light semantics
that unfold on click to traffic light semantics of all message
versions, which would (with precautions) visualize differences:
this can empower users to make decisions on the
trustworthiness of intermediates, and to, for example,
enable the above mentioned From: header field restoration.
</t><t>
However, the data exists in the DKIM "relaxed" normalized variant,
former states are not meant to be usable messages by themselves.
For example some embedded OpenPGP signature and text couple
would likely fail to verify, dependent upon the original MIME
transfer encoding.
</t><blockquote>
<em>Informative remark:</em>
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.
</blockquote><t>
Finally, the given example will likely verify as part of the
complete received message, unless altered along the SMTP path:
ACDC can ideally say where
(and exactly what, in an unbroken ACDC chain).
</t>
</section>
</section>
<section>
<name>Mitigations'25</name>
<t>
As of the time of this writing the email infrastructure is
deeply divided due to standards like DMARC and SPF, which
require mitigations to be applied in order to keep existing
infrastructures in a usable state.
</t><t>
For example, SPF will not survive a single hop, which means
that alias expansion, a widely used core feature of the email
infrastructure, does no longer work.
The IETF has no solution for this problem,
but the FOSS scene has created a "Sender Rewriting Scheme"
so that aliases can be used regardless.
</t><t>
As another example, DMARC caused a lot of mailing-lists to
apply mitigations in that either old DKIM signatures are
removed, or renamed, and that the From: header field is
rewritten in a "User A via List B" style.
</t>
<section>
<name>ACDC mitigations</name>
<t>
This memo suggests to apply active mitigations as part of DKIM
processing, temporarily, until, at some future time, the email
infrastructure has adapted to a (the) new reality.
Future engineers can then decide how to proceed further.
</t><ul><li><t>
Rename DKIM-Signature: header fields to DKIX-Signature:.
This mitigation <bcp14>MUST</bcp14> be applied.
(With a possible exception of the first, as below.)
</t><t>
Because DKIM-Signature: header fields are removed or renamed,
also by unanchored regular expressions, which would match for
example "EDKIM-Signature", ACDC aware software should rename
all elder ACDC enabled DKIM-Signature: header fields to
DKIX-Signature: upon egress.
</t><t>
Since only one DKIM-Signature: will have to be verified
successfully by non ACDC aware DKIM software, and ACDC aware
software can toggle the single byte back before verifying
elder signatures, this should be easy in practice:
just treat DKIM-Signature: and DKIX-Signature: alike,
but toggle before cryptographic verification.
</t></li><li><t>
Mitigate non-local <tt>MAIL FROM</tt>.
</t><t>
Because the SPF check will fail on the next hop if a message
that does not originate locally leaves the email system on
egress,
with a SMTP envelope <tt>MAIL FROM</tt> of a foreign domain,
mitigate such addresses.
DKIM software <bcp14>SHOULD</bcp14> offer options to exclude
certain domains from these mitigations.
</t><t>
To mitigate, synthesize an address of the local domain with a
<tt>local-part</tt> starting with <tt>DKIM=</tt>,
followed by for example at least 16 bytes of the
BASE64<xref target="RFC4648"/>
encoded
HMAC<xref target="RFC2104"/>
of a dedicated cryptographic private key
and the original <tt>MAIL FROM</tt>.
(The SMTP size limit of <tt>local-part</tt> is 64 octets,
however the overall "reverse-path" limit of RFC 821 and
RFC 2821 was 256 octets.)
</t><t>
The synthesized address <bcp14>MUST</bcp14> be linkable to the
original <tt>MAIL FROM</tt> for at least 864000 seconds
(ten days: to reach into the next working week).
It <bcp14>SHOULD</bcp14> be linkable only by message bounces
which have a verifiable DKIM signature of the local domain,
and it <bcp14>MAY</bcp14> only link for the signature of
the exact message for which the address was synthesized.
The optional bounce identifier "id" may be usable for this
purpose.
</t></li><li><t>
Mitigate From: header fields, if possible.
</t><t>
When a message was changed in between ingress and egress,
so that the DKIM signature related to the From: header
field will no longer verify,
and the From: header field was not already part of the
changes.
</t><t>
And/or if the <tt>MAIL FROM</tt> SMTP envelope changed
(possibly because of our own mitigations);
Then actively change the From: header field,
and place the original From: address in the Reply-To: header
field, unless that already exists.
</t><t>
Otherwise it is complicated.
Yes people, sorry, but now this would require a dedicated
sub-domain or address on the local domain,
and, effectively, the message must be actively turned so that
the current hop becomes the, quoting
<xref target="RFC3461"/>,
<em>"final delivery for the [original] message"</em>.
Luckily, this case here only applies to badly
configured company email system which forward from some
home worker, after applying certain footers on "spam"
or "legal notes".
At least in my world.
</t><t>
A "From: via MAIL FROM" notation <bcp14>MAY</bcp14> be used
(as in "display-name (local-part (AT) domain) via MAIL FROM").
</t></li></ul>
</section>
</section>
<section>
<name>Example</name>
<t>
An example that shows the flow of a single message with multiple
different recipients, including mailing-lists and aliases.
</t><sourcecode><![CDATA[
Originator (yet forged for recipient domain f.g):
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=1; s=K1; [email protected]; d=f.g; t=d; t=e; b=...
DKIM-Signature: acdc=1:O; s=K1; ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
...
f.g, local delivery (to d@ and e@):
...
DKIM-Signature: acdc=2:AIV; ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
[email protected] -- a mailing-list!
It redistributes after RFC 2369 and RFC 2919 additions,
in-message unsubscribe footer, and From: mitigated
(in best RFC 3461 manner):
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; d=m.n; t=l; b=...
DKIM-DC: sn=2; c=xz; h=BASE64; b=BASE64
DKIM-Signature: acdc=2:ADEOVYy; s=K2 ...
DKIX-Signature: acdc=2:ADEOVYy; s=K2 ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: a(AT)b(DOT)c via [email protected] <[email protected]>
...
List-Unsubscribe: bla
[email protected] -- an expanded alias!
The host honours RFC 3461, and changes MAIL FROM:
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; d=realv.realw; t=realu; b=...
DKIM-Signature: acdc=2:EOVy; s=K2 ...
DKIX-Signature: acdc=2:EOVy; s=K2 ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
[email protected] -- an expanded alias!
Note: will later fail SPF of [email protected] without Mitigations'25!
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; d=reals.realt; t=realr; b=...
DKIM-Signature: acdc=2:EVy; s=K2 ...
DKIX-Signature: acdc=2:EVy; s=K2 ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
[email protected] -- a mailing-list!
It redistributes after RFC 2369 and RFC 2919 additions,
in-message unsubscribe footer, without From: mitigation.
Note: will later fail DMARC of [email protected] without Mitigations'25!
(This is why DKIM-Signature "1" is not removed.)
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; d=X.X; t=X; b=...
DKIM-DC: sn=2; c=xz; h=BASE64; b=BASE64
DKIM-Signature: acdc=2:DEOVYy; s=K2 ...
DKIX-Signature: acdc=2:DEOVYy; s=K2 ...
DKIM-Signature: acdc=1:O; s=K1; ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
List-Unsubscribe: bla
[email protected] (recipient of x.y.z mailing-list), local delivery:
...
DKIM-Signature: acdc=3:IVYy;
DKIM-DC: sn=2; c=xz; h=BASE64; b=BASE64
DKIX-Signature: acdc=2:ADEOVYy; s=K2 ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: a(AT)b(DOT)c via [email protected] <[email protected]>
...
[email protected] -- expanded alias target, local delivery:
...
DKIM-Signature: acdc=3:IVy;
DKIX-Signature: acdc=2:EVy; s=K2 ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
]]></sourcecode>
</section>
<section anchor="IANA">
<name>IANA Considerations</name>
<t>
IANA is asked to create a registry of header fields that
shall be cryptographically covered by DKIM/ACDC.
This memo extends the list mentioned by
DKIM<xref target="RFC6376"/>
with the
Author Header Field<xref target="RFC9057"/>.
</t>
</section>
<section anchor="Security">
<name>Security Considerations</name>
<t>
Public-key cryptography is the safest approach to identification
of counterparts and verification of data.
This specification enables DKIM to cryptographically verify
SMTP envelopes, and to cryptographically verify all message
transitions back to the original message sender.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1123.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3461.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3463.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5863.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6377.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9057.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"/>
<reference anchor="BSDIPA" target="https://github.com/sdaoden/s-bsdipa";>
<front><title>BSDIPA, a mutation of BSDiff</title><author/></front>
</reference>
<reference anchor="LZMA2" target="https://tukaani.org/xz/xz-file-format.txt";>
<front><title>LZMA2: The .xz File Format</title><author/></front>
</reference>
</references>
</references>
<section anchor="FurtherDKIMUpdates">
<name>Further DKIM Updates</name>
<ul><li><t>
This specification obsoletes the simple canonicalization type;
It <bcp14>MUST NOT</bcp14> be used by software announcing ACDC.
</t><t>
<em>Rationale:</em> 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<xref target="RFC6376"/>
section 8.1 are considered to be a rather artificial attack vector.
</t></li><li><t>
This specification obsoletes the DKIM "l=" tag that restricts the
number of DKIM covered bytes of the normalized message body.
This tag <bcp14>MUST NOT</bcp14> be used by software announcing
ACDC support,
and all the message body <bcp14>MUST</bcp14> always be used to
create the body hash.
</t><t>
<em>Rationale:</em> "l=" has always been insufficient to deal with
message changes caused by mailing-lists etc,
but effectively includes the security risk that message parts which
are not covered by the signature appear as "valid content" to users
looking at a DKIM verified message.
The ACDC differential changes offer a better approach to deal
with message changes, while completely covered message bodies
ensure content validity.
</t></li><li><t>
For the "i=" tag this specification obsoletes the possible use of
DKIM-Quoted-Printable for the optional <tt>Local-part</tt>.
</t><t>
<em>Rationale:</em> because the syntax is "a standard email
address where the local-part MAY be omitted", quoted-printable
encoding is not necessary for representation.
</t></li><li><t>
This specification obsoletes the DKIM "z=" tag that was defined
"for diagnostic use" to copy a freely defined set of header fields
and their values present during signature creation.
This tag <bcp14>MUST NOT</bcp14> be used by software announcing
ACDC.
</t><t>
<em>Rationale:</em> the ACDC differential changes provide access
to the same information.
</t></li><li><t>
For the "q=" tag this specification obsoletes the possible use of
DKIM-Quoted-Printable for the optional <tt>x-sig-q-tag-args</tt>
of possibly introduced future query types.
</t><t>
<em>Rationale:</em> 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
<tt>hyphenated-word</tt> proxy identifier without making use of
byte values which would require encoding.
</t></li><li><t>
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".
</t><t>
<em>Rationale:</em> no use case has been encountered in the DNS,
let alone serious such; if future space unconstrained 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.
</t></li><li><t>
Because above changes remove all use cases for the
<tt>dkim-quoted-printable</tt> encoding defined in RFC 6376 2.11,
this specification obsoletes the DKIM-Quoted-Printable encoding.
</t></li><li><t>
This specification obsoletes the use of <tt>FWS</tt> in
<tt>ag-spec</tt>.
Second its use was never encountered by the author.
But first of all
MIME<xref target="RFC2045"/>
introduced parameters in ABNF as
<tt>parameter := attribute "=" value</tt>
without <tt>FWS</tt>,
and its presence complicates parsers and hinders parser code reuse.
The "acdc=" tag is defined without <tt>FWS</tt> support.
</t></li></ul>
</section>
<section anchor="Apologies">
<name>Apologies</name>
<t>
By accepting this draft the IETF recognizes that certain
developments of the past two decades mutilated the existing
email infrastructure to the point where it stopped functioning.
Without malicious intent this was the effective outcome of
trials to create a stronger security policy.
It left operators of for example mailing-lists and alias farms
without options to continue operating their infrastructure,
except through non-standardized, sometimes partial and imperfect
solutions created by third parties.
By applying mitigations through a standardized approach
it is hereby tried to create a solid foundation for a better
future.
</t>
</section>
<section anchor="Acknowledgements">
<name>Acknowledgements</name>
<t>
Thanks to, in the order of appearance,
Jesse Thompson,
Richard Clayton for arguments against reliance on header field
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,
and Bron Gondwana for the inspiration to split up binary
differences of headers and body.
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.
</t>
</section>
</back>
</rfc>
<!-- vim:set tw=1000:s-ts-mode -->
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
