Hello.
|Name: draft-nurpmeso-dkim-access-control-diff-changes
|Revision: 06
|Title: DKIM Access Control and Differential Changes
|Date: 2025-07-07
|Group: Individual Submission
|Pages: 19
|URL:
https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-control-diff-changes-06.txt
|Status:
https://datatracker.ietf.org/doc/draft-nurpmeso-dkim-access-control-diff-changes/
|HTML:
https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-control-diff-changes-06.html
|HTMLized:
https://datatracker.ietf.org/doc/html/draft-nurpmeso-dkim-access-control-diff-changes
|Diff:
https://author-tools.ietf.org/iddiff?url2=draft-nurpmeso-dkim-access-control-diff-changes-06
Shrunk away truths noone wants to hear. (Quite a diff.)
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. [.]
It fixes all issues known to me:
- DKIM-AC: header fields (SMTP envelope protection) are now
cryptographically bound to their DKim-Signature (huch).
- Flag state machine was worked over.
I had totally forgotten how nicely RFC 3461 laid out grounds
for "final delivery for the [original] message" and "new
envelope return address"es!
(A draft iteration would surely point even more back to that!)
Given this official standard i could remove Dave Crocker's
quote.
Changes:
- DKIM-AC: and DKIM-Diff: now use DKIM-style "tag="s.
The _dkimacdc DNS entry was refined.
- DKIM-AC: header fields are now always generated.
Of course only ACDC aware recipient domain will be able to deal
with them, somehow; and they are still removed by those.
Other domains require message forging that takes public
To:/Cc: and hidden Bcc: into account.
For simplicity single-recipient delivery is also possible.
-- The per transaction recipient limit for ACDC aware domains
is now configurable via DNS.
-- The default limit is now only half that of the SMTP standard.
- DKIM-Diff: splits diff of headers "hd=" and body "bd=".
This (massively) reduces BSDiff processing cost (if the "bh="
body hash did not change).
New:
- Added LZMA2 support as a compression method for the BSDiff
output. Whereas the processing costs are higher, the I/O
reduction may effectively result in (huge) savings.
(All relative, of course.) MUST for verifiers only.
(The FOSS implementation S-bsdipa ships with this out of the
box, inclusive support for I/O cookies which can massively
reduce allocation costs in a long running program; cookie for
XZ aka LZMA2 only (yet). Still Coverity.com 0.0 defects.)
- Flag state machinery now knows about "I" signatures, which
then can also have "S" and "s".
Verifiers now simply create a temporary signature to announce
verification state, and this can now also include SPF checks.
("I" signatures are removed on egress.)
- Asks IANA to create "a registry of header fields that shall be
cryptographically be covered by DKIM/ACDC".
It already adds (ed) Author/RFC 9057 (in the past).
And also there is a new Mitigation'25 section. This is work in
progress. Because, you know, whereas removed from the draft, the
email state of affairs is a disaster, and the IETF makes it only
worse. And it is a shame that other people have to come over with
solutions because the IETF just does not.
And because the iterated DKIM must know about "cache" (with timing
out entries), it makes absolute sense to simply include solutions;
the solutions are effectively simple, if a certain approach is
agreed to!
So, one mitigation that is already defined is that my approach
actually does work today, different to what i stated in -05, even
though DKIM-Signature header field instances are removed or
renamed. DKIM/ACDC simply renames itself, to DKIX-Signature (not
EDKIM- because of unanchored regular expressions that may be used
to remove them); this is only a byte toggle, it must be reverted
before verification. And so the only DKIM-Signature that leaves
a DKIM/ACDC signer exists as DKIX- also, right away.
*I would* add mitigations for SPF and DMARC, to satisfy the
abstract quoted above.
I have not provided any examples, i was happy to make it about
half an hour before the doors closed, so to say.
(I mean, it is DKIM RFC 6376, and you have some flags dependent
upon the detected state in the "acdc=" tag. Diffs are generated
as necessary, and access control headers are created upon envelope
changes. Say
Originator (message 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]; dr=f.g; rt=d; rt=e; b=...
DKIM-Signature: acdc=1:O; s=K1; ...
From: [email protected]
To: [email protected], [email protected], [email protected], [email protected]
bla
f.g, local delivery:
...
DKIM-Signature: acdc=2:IV; ...
DKIX-Signature: acdc=1:O; s=K1; ...
...
[email protected] -- a mailing-list! It sends further along, and From:
mitigated:
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; dr=X.X; rt=X; b=...
DKIM-Diff: sn=2; c=xz; hd=BASE64; bd=BASE64
DKIM-Signature: acdc=2:DEOV; ...
From: a(AT)b(DOT)c via [email protected] <[email protected]>
...
List-Unsubscribe: bla
[email protected] -- an expanded alias! The host honours RFC 3461:
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
...
DKIM-AC: sn=2; s=K2; [email protected]; dr=realv.realx; rt=qreal; b=...
DKIM-Signature: acdc=2:EOV; ...
DKIX-Signature: acdc=1:O; s=K1; ...
From: [email protected]
...
Late it is. Yaaawn. I hope the above is right. ;)
It is the future of email for email of the future.
--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
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
