Michael Thomas wrote in <1dbce124-0e1c-4f05-b827-60025684e...@mtcc.com>: |On 3/5/25 12:29 PM, Tobias Herkula wrote: ... |I've been reading the draft mentioned in the charter re: replay and |rcpt-to and don't understand why that changes anything wrt replay. If |there is a message that a spammer has discovered passes a recipient's |spam filter, what difference does it make if it's a single smtp |transaction or multiple transactions? | |If the idea is that it is somehow bound to the original rcpt-to, that |breaks a significant amount of use cases in the email architecture |(forwarding) so I sure hope it's not that. The draft does sort of imply |that a Bcc'd address will end up in the signature block, which |completely defeats the purpose of Bcc which sounds like a really bad idea.
Dear Michael Thomas, do you refer to the ACDC draft here? This .. "cannot be" in regard to Bcc and the signature block, as these are additional per-receiver-domain subsignatures, only produced if that domain announces ACDC support via DNS. In at least in DNSSEC cases this asserts ACDC support, and that will remove these subsignatures before delivery. Intermediate hosts which fish such a message to send it somewhere else will cannot replay against ACDC aware receivers with it. It is true, however: they can use such message instances for replay attacks against non-ACDC aware hosts. It is true, man-in-the-middle could repost the same message to the same receiver domain over and over again. This could only be addressed with a receiver domain cache on some unique key, like the message id, or simply the subsignature as such? (DKIM2 has a nonce, well, if all else fails, UUID, to give a hand to the receiver to implement such? Could be added, of course. Should it? Or should it be an implementation guideline? One could directly use RFC 9562, and add an according field to the subsignature; or -- WAIT! Actually the current draft includes a bounce id already, in the ACDC tag of the regular DKIM-Signature: id = *20(ALPHA / DIGIT / "+" / "-"); optional bounce ID It could be made mandatory, and documented accordingly!) It is also true that two or three years ago, when i posted on this list that raw "subsignature" idea first, i wanted to encrypt the subsignature header with a key that the receiver domain would announce via DNS. The idea by then was i think that all such subsignatures would and could be included in the message, i had to look for what i wrote exactly; length padding would have been a necessity etc then i would think, to make all equal, whatever this means, it also and already reveals things ... I still think this would be a good thing, even though it seems to me that most of the time we either have a (what is supposed to be a) host-to-host connection, or submission plus host-to-host. Public key cryptography is a problem beside that. There are not many algorithms which can be used i think (i am not a cryptography expert), and RSA is then again fat. Some crypto libraries support encryption with Ed25519, but OpenSSL did not follow this, for example. So you could create a random key, encrypt data with that random key, use the DNS announced public key to encrypt the random key, then the receiving host can decrypt the key, and decrypt the data with that key. I think the new chinese algorithm can this officially, and maybe OpenSSL will support that in the future? Other than that, RSA is fat. You also said |If the idea is that it is somehow bound to the original rcpt-to, that ACDC comes with an "O" flag: any intermediate host can reclaim ownership, like a mailing-list that distributes a message to all senders. This goes in line with Dave Crocker's saying that for him ~"even forwarding" ~~"shall be treated as" what is actually quoted in ACDC: 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. Since ACDC integrates into the current environment, DMARC, ARC, and all that, it is in use, and of course messages have to continue to comply to their constraints. With aliases especially SPF is problematic it seems to me? The sender does not know that the rcpt-to is an alias, and so nothing should change here? --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 -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
