Larry M. Smith wrote in
<[email protected]>:
|Sorry, I'm a bit late to the party. While I have attempted to follow
|the discussion, here are some initial thoughts after a bit of pondering.
| I might have missed if these were discussed elsewhere and I might very
|well be wrong in my understanding of how this system might work.
|
|DKIM replay.
|
|I appears to me that most of what has been discussed with regards to
|DKIM replay is an attempt to abuse systems that use DKIM for positive
|reputation. However, such replay does require that the messages pass
|DKIM signing.
|
|Hypothetically, if I were evil[1], I would sign up for a target domain's
|newsletter and mutate messages with this DKIM2, and resend them. While
|forensic investigation would reveal the subterfuge, what gets displayed
|via the user's MUA is verifiable via DKIM2 and presumably trusted. I
|expect overuse of m=nomodify and this Could make the motivation for
|DKIM2 somewhat moot.
|
|An example;
|
|1) I sign up for email from [email protected].
|2) When I receive new email message I mutate them hijacking the donation
|links, maybe modify the message is subtle ways, DKIM2 sign the emails
|appropriately, and resend them to my list of victims.
|3) Receiving systems validate the DKIM2 and accept the messages.
|
|[1] I do realize that some reading this might believe that the
|hypothetical in that statement is the word "if"
For this you likely change both, the RFC 5322 IMF message, as well
as the RFC 5321 SMTP envelope. Both of these require, with my
DKIM v1 ACDC thing at least, to "become the origin of the
message", or there is no successful verification. Now what this
means exactly in real life noone can tell (yet), but it is, at
least, a tremendous break, also by standard terms.
ACDC (though not (yet) in standard terms) also implies DMARC
mitigation for the IMA:
<em>Informative remark:</em>
It follows that the "changes cause a new message"
paradigm of today's DKIM/DMARC usage stays intact.
It is deemed correct behaviour:
<em>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.</em>
(Dave Crocker.)
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.
This means for example that the From: header should (must) be
rewritten. Then the recipient of *your* email will see that the
message is not from the original author.
(As said, "not in standard proof terms", but it is meant like
that -- even if no DMARC DNS record is provided that would cause
From rewriting of mailing lists, because the original DKIM
signature *will* break (or would if not removed).)
|Security gateways and ARC
No.
|Bounce pathing
|
|Current architecture of an overall mail systems may result in a
|forwarder not being directly accessible for the general Internet. I.e.
|there might not be a path to port 25, or any other port, to anyone
|outside of the local site. This might create issues.
DKIMACDC solely builds upon SMTP. There is no bypass.
It only provides security for the envelope, replay, and the
possibility to undo differential changes.
--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)
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
