On 4/11/2025 1:02 PM, Richard Clayton wrote:
>> 4.5. The "mailing list DMARC issue"
>>
>> *Issue:*
>>
>> Once an intermediate (for example, a mailing list or alumni
>> forwarder) makes a change to the header or body of a message, the
>> hashes covered by the sender's DKIM signature no longer match, and
>> it's not possible to see whether the message is semantically
similar,
>> or has been completely replaced by a bad actor.
> Breakage depends on whether DKIM was covering the portion that got
changed.
> If preservation of the content is that important, use a
content-protecting
> mechanism that is more likely to survive a re-posting. Choices are
already
> available, and have been for decades.
> If you don't like the choices, consider defining a mime-based
protection
> mechanism that is independent of DKIM, while re-using DKIM's design
approach.
> My guess is that the concern stated here is rather more specific
than is
> stated.
It could be argued that only people who attend IETF meetings care about
this issue, everyone else has mitigated it and moved on ... however, it
is in the Working Group charter so it is going to be tackled
Please consider offering a response that has to do with the substance of
my comment.
>> *Mitigation:*
>>
>> DKIM2 will define an algebra for describing how to reverse any
>> changes to create the prior binary data, by inspecting the diff
>> between the two versions, recipients will be able to see who
injected
>> bad content.
>>
>> Mailing lists (or alumni forwarders etc.) that alter the Subject
>> header field (or other [RFC5322] headers) will record the previous
>> header field contents. This is easy to undo for checking purposes.
>>
>> Mailing lists that add text (either to a simple email body or
one or
>> more MIME parts within the body) will record details of the
text they
>> have added. This text can then be removed when checking earlier
>> signatures.
>>
>> We expect the "algebra" describing changes to be in a stand-alone
>> document that need not be finalised on the same timescale as DKIM2
>> itself.
> This is going to cause significant collateral damage, as its use
becomes
> ingrained and/or widespread:
> This is going to define a set of 'acceptable' changes by
> intermediaries and will result in calling other changes a 'problem'
> or even an 'error'. (cf, calling legitimate From: addresses
> 'spoofed'.)
> *This will further marginalize mail that is entirely legitimate, but
> which does not fit into an increasingly Procrustean model.*
I think these are comments which you should put into a review of
draft-gondwana-dkim2-modification-alegbra
rather than here, in particular that document does not currently
constrain changes in any way...
And yet, here is where there was text I was commenting on to.
>> *Migitation:*
>>
>> DKIM2 headers will always have timestamps so that "old" signatures
>> have no value.
> Reports of replay attacks have indicated that replay can and does
happen, well
> within normal email handling time-frames. So the timestamp is of no
help.
it does help with mitigation techniques (which may still be useful in a
DKIM2 world if attacks continue -- which they may not since they will be
far less likely to be widely successful)
Since I explained why it likely does not help, what we need is a
response that covers the substance of how it does, rather than simply
getting a declaration of assurance that it does.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
